On Wed, 9 Sep 2015, John R. Levine wrote:
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(_at_)example(_dot_)com, the bank's then automatically
looks up the key (likely the same as for john(_at_)example(_dot_)com,) 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.
For the internet scale domains, the local part rules are well known and
can be implemented by clients doing a lookup. They could even decide to
do based on the identity of the MX server (eg google domains). A few
people strongly objected to even hinting at common rewrite rules, so
that information was removed from the draft (not so much by consensus
but for conflict avoidance). Re-adding this advise would resolve this.
Another suggested method has been the addition of a domain-wide special
TXT record that describes the domain rewriting rules. However, the WG
was ready to start an experimental deployment and use the results of
those experiments to write a bis document, possible promoting such a
bis document from Experimental to Standards Track.
The WG considered and rejected reversible encodings,
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.
I am not sure what you base this on. While MUA's indeed have the luxury
of being able to fallback to asking a human for confirmation, one of
the main goals of the draft is to facilitate automatic email encryption
without human interaction.
If that's the use model
It is not "the" use model. The introduction of the document even talks
about how the old HKP servers are unusable for automatically encrypting
email due to a lack of authentication of the openpgp keys.
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.
Just to clarify, the document does not expect or suggest any changes to
the SMTP protocol or RFC-5321. I assume that with "modifying incoming
addresses" you mean modifying the DNS lookup for the openpgpkey record,
not the SMTP envelope values.
There was proposed text to only perform lowercasing for the QNAME in
the DNS lookup when the LHS was in ASCII. That would prevent any issues
with internationized email names. The reason lowercasing is needed is
because it is well known that webforms and phone virtual keyboards often
auto-capitalize names that appear in built-in dictionaries. Additionally,
there are no known deployments where the case of the LHS matters. Humans
simply cannot handle that paul(_at_)nohats(_dot_)ca is a different user from
Paul(_at_)nohats(_dot_)ca. Lowercasing is simply not a problem for ASCII names.
An alternative approach was also suggested where if the client detects
the LHS can be lowercased, and an unmodified lookup yields no record,
that it would be allowed to perform a second lookup lowercased.
The only argument against either of these were dogmatic and based on
illusionary mailservers that could be implementing different mailboxes
for "Paul" vs "paul" local-parts.
I still believe the draft would be greatly improved if either one of these
solutions were added back to the document. Obviously, implementors should
not ignore the auto-capitalization problem. While it would not lead to
interoperability problems, it could lead to a decrease of Opportunistic
Security.
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.
As far as I'm aware, some of these 10^8 or 10^9 actually don't use flat
zone files but use online DNSSEC signing with database backends.
Regardless, one would expect an infrastructure for 10^9 mailboxes would
be able to run an online signer on the _openpgpkey.example.com domain.
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.
I'm not sure how local part partitions for mailboxes are affected at
all. Mail is delivered either encrypted or not encrypted, to the
identical local-part. This draft does not require any modification on
the part of the SMTP server. Partitioning still works.
Partitioning DNS answers is a very well understood feature called "DNS
split view" and are often in use for localising DNS answers based on
geographic IP of the query. Various very successful companies deploy
these technologies.
PGP key records are about 3K
Not if the recommendations of Section 2.1.2 are followed.
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.
Clearly, online signing would be used in such a large deployment.
In one sense it doesn't matter since
large mail systems are unlikely to implement this (I asked)
Obviously, the large mail systems that base their business model on
reading the emails for targeted advertising are not the main target for
deployment of this document - the other 50% of the internet is.
* 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.
The only "guessing" that the document has ever suggested in its
previous drafts were lowercasing or rewriting based on well-known
domain properties. It has never attempted to do the "guessing" you are
listing above.
The document is about attempting to encrypt email that otherwise would
go out in plaintext. It clearly states it is not a replacement for
using authenticated pre-arranged encryption. The main focus of the
document is to prevent pervasive monitoring of plaintext email in
transit and stored on intermediate email servers. So failure to encrypt
john+bank(_at_)example(_dot_)com is not a security failure. It is merely the
failure of adding Opportunistic Security.
PS: For a different approach, see draft-moore-email-addrquery-01.
I encourage deployment of alternative encryption authentication methods.
The method of draft-ietf-dane-openpgpkey is based on DNSSEC. One of its
features is that misbehaviour by the email server can be spotted by
the enduser. They see their OPENPGPKEY record being modified without
their consent. It seems the method of draft-moore-email-addrquery-01
relies on fully trusting the SMTP server, which is not secure
if the email provider can be coerced by a third party. Therefor,
draft-moore-email-addrquery-01 is an alternative approach, but not a
replacement of draft-ietf-dane-openpgpkey.
Paul