Subject: [dane] draft-ietf-dane-openpgpkey

From: Stephan Bosch <[email-masked]>
Date: Mon, 01 Jun 2015 16:05:42 +0200

Hi,

I just read the dane-openpgpkey document and discussed it a bit with a 
friend. And now, we have a question. I must say, I haven't followed the 
discussions on this mailing list much lately, but I couldn't find an 
answer to this question by quickly browsing through the openpgp-related 
threads.

 From what I can tell, this document only describes how to publish and 
retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any 
mention of a procedure by which a key would get published. Since the 
domain would be controlled by the mail provider, the user cannot do this 
directly. So, how does a user go about getting his public key published 
in the DNS? What kind of interaction do you envision between the service 
provider and the mail user? Some kind of provider-specific web 
interface? Would it be useful to devise some standardized (sub-)protocol 
for this, so that a MUA can easily arrange this for the user (e.g. just 
after it generated the key pair)?

Regards,

Stephan.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Jun 2015 11:44:59 -0400 (EDT)

On Mon, 1 Jun 2015, Stephan Bosch wrote:

> retrieve a key in DNS/DNSSEC, i.e. in what format. I don't see any mention of 
> a procedure by which a key would get published. Since the domain would be 
> controlled by the mail provider, the user cannot do this directly. So, how 
> does a user go about getting his public key published in the DNS? What kind 
> of interaction do you envision between the service provider and the mail 
> user? Some kind of provider-specific web interface? Would it be useful to 
> devise some standardized (sub-)protocol for this, so that a MUA can easily 
> arrange this for the user (e.g. just after it generated the key pair)?

While that would be nice, the problem is how you authenticate that to
your ISP or mail hoster, DNS hoster or DNS webgui interface. I doubt
that you could find enough common ground for an authentication method
between those parties.

There are tools (like hash-slinger's openpgpkey command) that can
generate the DNS records. Those have to somehow get inserted into the
zone. Whatever the method is to get an A record in, is the method to
get an OPENPGPKEY record in.

It would be awesome if facebook (who announced pgp support today) or
google or yahoo would allow some method of receiving your public key[*]
but I would think those parties would convert your message into the
appropriate DNS record format.

Paul
[*] For instance a message "please publis my key" signed with that key
     uploaded through their HTTPS / authentiacted website.

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 01 Jun 2015 18:16:58 +0200

Hi Paul,

Paul Wouters schreef op 1-6-2015 om 17:44:
>> domain would be controlled by the mail provider, the user cannot do 
>> this directly. So, how does a user go about getting his public key 
>> published in the DNS? What kind of interaction do you envision 
>> between the service provider and the mail user? Some kind of 
>> provider-specific web interface? Would it be useful to devise some 
>> standardized (sub-)protocol for this, so that a MUA can easily 
> your ISP or mail hoster, DNS hoster or DNS webgui interface.

Well, I suppose using the same credentials used to read/send e-mail? For 
this, I am assuming the mail hoster is the same entity that controls the 
domain and can freely modify the _openpgpkey.mail.domain.tld zone. So 
this would mean that a DNS update results from a user's key publication 
request, as received from a yet-to-devise protocol that is authenticated 
using SASL with the same credentials as IMAP/POP3 and SMTP-submission. 
It could even be done from within those protocols with some extension, 
e.g. using IMAP METADATA.

Any other means would be fine too, as long as it is simple enough and a 
standard that MUAs can rely upon.

> I doubt that you could find enough common ground for an authentication 
> method
> between those parties.

I hope there is some common ground to be found. Otherwise, I fear this 
new technology could fail in terms of user/MUA adoption. Getting the key 
out there should be as easy as possible.

>     uploaded through their HTTPS / authentiacted website.

Yes, but all of this would be provider-specific, which I think is bad.

Regards,

Stephan.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Jun 2015 12:38:55 -0400 (EDT)

On Mon, 1 Jun 2015, Stephan Bosch wrote:

> domain and can freely modify the _openpgpkey.mail.domain.tld zone. So this 
> would mean that a DNS update results from a user's key publication request, 
> as received from a yet-to-devise protocol that is authenticated using SASL 
> with the same credentials as IMAP/POP3 and SMTP-submission. It could even be 
> done from within those protocols with some extension, e.g. using IMAP 
> METADATA.

While this works, you have now reduced the openpgpkey security to an
email password. Anyone with that password can now replace the
openpgpkey of the user. While it is a good starting point, there would
have to be more to secure it, for instance replacing could require
a signing by the old key of the new key (or manual intervention using
support@isp)

> I hope there is some common ground to be found. Otherwise, I fear this new 
> technology could fail in terms of user/MUA adoption. Getting the key out 
> there should be as easy as possible.

Agreed. And I think it would be useful to write another document on an
SMTP/IMAP extension for doing so. I don't think it should go into the
existing OPENPGPKEY DNS/DANE draft.

> Yes, but all of this would be provider-specific, which I think is bad.

Agreed it is terrible, but you'd want the openpgpkey to be somehow more
secure than an email password (reset).

Paul

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 01 Jun 2015 20:44:02 +0200

Hi Paul,

On 6/1/2015 6:38 PM, Paul Wouters wrote:
>> Well, I suppose using the same credentials used to read/send e-mail?
>> For this, I am assuming the mail hoster is the same entity that
>> controls the domain and can freely modify the
>> _openpgpkey.mail.domain.tld zone. So this would mean that a DNS
>> update results from a user's key publication request, as received
>> from a yet-to-devise protocol that is authenticated using SASL with
>> the same credentials as IMAP/POP3 and SMTP-submission. It could even
>> be done from within those protocols with some extension, e.g. using
>> IMAP METADATA.
>

I think manual intervention is best avoided if at all possible.

We could devise this new protocol (or whatever) as only a standard entry
point for submitting a new key. What happens after submission does not
strictly need to be standard. It could then involve some side-channel
like sms or snailmail with some sort of (PIN) code and some subsequent
confirmation, so that the key is only posted to the DNS once this
provider-specific procedure is completed successfully. Submitting the
final PIN code (or whatever) could also be part of the new protocol. So,
then only the means by which this code is conveyed would be left
unspecified. Also, if security requirements are less high, this
secondary verification stage could be omitted, relying solely on the
SASL authentication.

This kind of procedure is used quite often already in the field for
various types web services, and I think it could help here as well.

>> I hope there is some common ground to be found. Otherwise, I fear
>> this new technology could fail in terms of user/MUA adoption. Getting
>> the key out there should be as easy as possible.
>
> SMTP/IMAP extension for doing so.

Same story for S/MIME of course.

> I don't think it should go into the existing OPENPGPKEY DNS/DANE draft.
>

I agree.

> secure than an email password (reset).

Yes.

Regards,

Stephan.

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2015 17:10:05 -0000

>mention of a procedure by which a key would get published. ...

As others have noted, that's true.

For one thing, this draft and the companion S/MIME draft have serious
design problems* that make it unlikely that they will be adopted
outside of small niches, so I wouldn't put a lot of effort into fixing
them.

But more important, most DNS management systems are protected with
passwords now.  That's how the management consoles at domain
registrars work (they control the NS records) and it's how most DNS
management consoles work.  Some use hardware or software tokens or
client certs, but most don't, so there's little point in building a
steel door for those cardboard boxes.  Even if there are super-secure
HSMs for zone signing, they can only sign what the DNS management
system already has.

The PGP certs you would retrieve would presumably have the same WoT
endorsements as if you retrieved them any other way, so you can
continue to use WoT to decide whether to accept them.

R's,
John

* - not just the address guessing issue, see zillions of messages in
the list archive for details