Re: Last Call: <draft-ietf-dane-openpgpkey-05.txt> (Using DANE to Associate OpenPGP public keys with email addresses) to Proposed Standard

["John R. Levine" <[e-mail]>]

> - 'Using DANE to Associate OpenPGP public keys with email addresses'
>  <draft-ietf-dane-openpgpkey-05.txt> as Proposed Standard

This draft has several technical issues that will make it a problem to 
interoperate at Internet scale.  They've all come up in the WG mailing 
list, but they're still unresolved.

It would be great if there were a workable automated way to discover an 
encryption key for an address.  I'd like to sign up on my bank's web site 
with the tagged address [e-mail], the bank's then 
automatically looks up the key (likely the same as for [e-mail],) 
and after that the mail they send to me is encrypted to my key, and they 
can verify that the mail I send to them is signed with my key.

* Name semantics

The SMTP specs have always said that the local-part of an e-mail address 
(the part before the @) is only interpreted by the recipient MTA.  MTAs 
invariably map a lot of different local-parts to the same internal 
mailbox.  They do ASCII case folding, drop noise characters (Gmail's 
dots), trim extensions (user+ext), do LDAP lookups, and more, with great 
inconsistency among mail systems. The DNS does exact matches other than 
ASCII case folding and wild cards, neither of which seem relevant here.

Every variation that can be looked up using this scheme has to be put 
separately in the DNS, as a key record or a CNAME, so the number of 
variations that a user can look up will be only a tiny fraction of the 
total. The WG considered and rejected reversible encodings, e.g.  base32, 
that would allow a specialized DNS server to recover the local-part, pass 
it to the relevant MTA to find the mailbox and then sign and return an 
appropriate key record.  Since it appears unlikely that anyone would ever 
implement that, I agree it's not a solution.

>From discussions on the WG list, the plan appears to be that lookups will 
be made manually by human users who will pick addresses they think are 
likely to be in the DNS, e.g., lower case without extensions.  If that's 
the use model, the draft should say so explicitly and make it clear that 
most addresses that work in SMTP won't be in the DNS. We should consider 
whether such a narrow use case is worth it.

It also appears that they expect users and maybe MUAs to modify incoming 
addresses (the draft now says not to but the author recently said he wants 
to put back case folding advice, as did some last call comments), arguing 
that in practice all MUAs treat upper and lower case as equivalent. 
While that may well be true for ASCII addresses, it is a significant 
change to RFC 5321 address semantics.  If we're going to make that change, 
it should be an update to RFC 5321, not an end run.

* Scaling

Mail system sizes range from a handful of users to some with over 10^8 
users and possibly one with 10^9.  There are three mail systems in the 
U.S. with over 10^8 users that handle about half of all the mail in the 
country.

Hashed names require that all of the keys for a domain be served in one 
flat zone.  Large mail systems typically partition the users based on the 
local part, but since the hashes aren't reversible, there's no way to tell 
what partition would handle what hashed name. The server might broadcast 
queries to all the partitions, but that just pushes the problem down a 
level, since there's still no way to tell what address matches a query 
without a precomputed table of hashes.

PGP key records are about 3K so a zone with 10^8 keys, which would be 
under 1/4 of Gmail's or Yahoo's users, would be 300 gigabytes before 
signing. The largest signed zone now is probably .COM at about 10GB before 
signing; a zone 30 times as big seems rather a stretch.  In one sense it 
doesn't matter since large mail systems are unlikely to implement this (I 
asked), but at the least the draft should document the scale problems for 
large systems.

* Security and name guessing

Absent a change to RFC 5321 name semantics, this draft pretty much demands 
name guessing.  If Bobsmith@example doesn't work, try bobsmith@ or 
BOBSMITH@ or BobSmith@ or maybe just bob@.  If john-bank@example doesn't 
work, maybe john@ or JOHN@ will.  Key guessing in a security protocol 
seems oddly insecure.

R's,
John

PS: For a different approach, see draft-moore-email-addrquery-01.