- '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.