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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



- '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 john+bank@xxxxxxxxxxx, the bank's then automatically looks up the key (likely the same as for john@xxxxxxxxxxx,) 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.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]