ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Keyserverless Use of OpenPGP in Email

2016-04-12 08:40:36
I have, and it indeed solves the ddos-problem of keyservers. It still
requires connectivity, introduces an arbitrary lookup delay, leaks
metadata, and most importantly - it's not deployed. I would love to see
it in action at scale, but even on my most hopeful of days I reckon it
will be years until it's commonly supported by mail providers.

 - V

Paul Wouters(paul(_at_)nohats(_dot_)ca)@Tue, Apr 12, 2016 at 10:15:36AM -0300:
Have you looked at the openpgpkey DNS record which is going to be an RFC very 
soon?

https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-07

Paul

Sent from my iPhone

On Apr 12, 2016, at 09:15, Vincent Breitmoser <look@my.amazin.horse> wrote:

Hi,

(crossposting to openpgp-email and openpgp-wg, the lists where I expect
the highest rates of interested people)

I'd like to discuss a thought that has come up in my work on k9 mail:
Using OpenPGP in E-Mail without relying on keyservers.  As a motivation,
just consider someone spins up their botnet to add 1000 or more keys per
second to the pool - aaaaand it's gone. Other aspects are that a
keyserver lookup requires network connectivity, introduces noticable
delay, and has privacy implications which prevent us from doing the
lookup in an automated fashion.

First, some basic considerations:  To obtain the public key of a
communication partner, we obviously have to rely on said communication
partner to make their key available to us one way or another.  The only
deployed lookup mechanism are keyservers, but we said we don't have
that.  The alternative is sending the key in-band with the particular
communication protocol: No problem for synchronous communication such as
XMPP because we can simply request them, more difficult for e-mail where
that option is not available.

If we don't have bandwidth constraints, we can solve this by sticking
the public key block right next to every signature we make, which
effectively eliminates the need for keyservers (with the possible
exception of the distribution of revocation certs).  However, it also
adds ~10kb of size to every signature.  This is a rather extreme
approach, and although 10kb are not a lot these days, they add up.

To counteract this, we can significantly reduce the number of attached
public keys if we are just a little bit clever about the decision of
when to add it.  Roughly, it makes sense to attach the public key to the
first message of a conversation with each recipient.

Another question is, where to place the key. In email, we have two
options: in a separate mime part, or directly next to the pgp signature
data. I favor the second option, for two reasons:
- the email client has to know a lot less about openpgp for this to
 work, the public key is naturally handed to the openpgp-implementation
 together with the signature data.
- there isn't yet another weird attachment for recipients who don't have
 openpgp support
- the intended purpose of the key is clear, because there are no other
 circumstances where a key might end up in this position.

The drawback with this approach is implementation support.  If an
implementation doesn't expect a public key next to the signature data,
it's just bloat (or even worse, produces a warning about trailing data.
I did some tests and this is the case in mutt, but not enigmail), and
does not even show an option for the user to manually import the key.

I think that this approach might be a way to overcome the need for a
click from the user (whether it's "Retrieve from Keyserver" or "Import
from Attachment") to be able to import and work with a public key. It's
unacceptable to import a key from keyservers automatically for various
reasons, but I think an opt-out behavior of importing keys retrieved as
part of a message is fine, if that key also signed the message.

I'll leave it at this for now.  I'd be delighted about comments and
thoughts, in particular from those of you who are involved in the
decision making of other implementations.

- V

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

Attachment: signature.asc
Description: Digital signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp