Re: [openpgp] Keyserverless Use of OpenPGP in Email

[Vincent Breitmoser <[e-mail]>]

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([e-mail])@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 <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/openpgp
>