On Fri, 11 Sep 2015, John C Klensin wrote:
the I-D warns against that case). On the other hand, if the
MUA, having decided that the two addresses are equivalent, sends
the encrypted message to the joesmith mailbox, then information
the sender believes is being transmitted encrypted is disclosed
to the wrong party.
Luckilly, "joesmith@xxxxxxxxxxx" and "Joesmith@example".com are
already really good hypothetical friends. They have been regularly
receiving each others unencrypted email for the last 20 years.
I believe that whole scenario is a bad idea and is one of
While others believe that webforms and phone virtual keyboard auto-correct
functions that changes "joesmith@xxxxxxxxxxx" to "Joesmith@xxxxxxxxxxx"
is an _actual_ problem to address, happening to actual people every day
and not some theological and hypothetical deployment.
In the real world, the local-part is not case sensitive.
several reasons why originating MUAs should not start
algorithmically guessing at names
It is not guessing. It is a defined transformation. Leaving lowercasing
out of the spec will result in most implementations querying the
unmodified and the lowercased versions to support webforms and virtual
keyboard auto-capitalization. And some implementations will forget to
implement this because it wouldn't be mentioned in the spec, and it will
cause some people's email to go out unencrypted where it could have gone
out encrypted. But we would have saved the imaginary Joe Smith and joe
Smith from receiving each others unreadable email. At least they will
still have each others unencrypted email to read.
--and IETF specs, even
experimental ones, should not encourage doing so-- even though
5321 does not (and cannot) explicitly prohibit it. If the
advocates of this spec believe the level of risk is acceptable,
I believe they _MUST_ carefully describe that risk and the
tradeoffs in their Security Considerations section.
I am totally willing to do that, once we can find one instance out of
the 10^9 email addresses where two different people have identical email
addresses apart from the case of the local-part. I suspect the change
of finding that is going to be smaller than that of a hash collision
in DNSSEC or OpenPGP.
Because this is a security protocol, I'm even more concerned
about false positives because the sending MUA has no way to know
whether joe+smith@xxxxxxxxxxx and joe.smith@xxxxxxxxxxx
The document has never in any of its iterations stated that the "+" or
"." symbol should be removed before hashing, let alone that they should
be juxtaposed in the way you are describing, so your concern is unfounded.
users are not, and never have been, uniquely bound to mailboxes.
The OPENPGPKEY record is not about users, it is bound to email addresses.
(or as you can call them, mailboxes)
In the PGP case in particular, it is not an accident
that the key format contains provisions for several addresses
associated with a given user, addresses that are individually
signed/ certified/ validated.
And OPENPGPKEY records can be deployed on any of these indepedantly,
and the draft even suggests removing those IDs in the key that are
not referring to the mailbox for which the OPENPGPKEY is being created.
If the user and MUA want to be able to employ DNSSEC to obtain
keys for correspondents well outside their social circle, it
is not reasonable to call these keys "bogus". They are
certainly less "bogus" than most web site (DV) certificates.
One of us misunderstands DNSSEC. It doesn't obtain anything.
It merely provides validation of one thing and one thing only,
which is an integrity check that a response to a DNS query
reflects what is actually in the DNS. It is not, as the draft
can be read to assume or imply, a magical form of pixie dust
that, e.g., attests to the binding between a key found in the
DNS and a particular external user identity.
It seems we have already established a nice family of pixie dust
with the SSHFP, CERT, TLSA, IPSECKEY and CAA records. And of
course other records also publish data on the assumption that
the consumer can trust it due to DNSSEC, such as SPF/TXT records.
DNSSEC is used as a PKI. Half the people who built DNSSEC,
set out to build it as a PKI from the start.
I'm not sure what that means, but you have, IMO, just
strengthened my argument that the Security Considerations
section of the draft is completely inadequate as a discussion of
the vunerability and risks associated with this approach.
You mean, the risk of an MTA receiving a plaintext email and
sending it on as a plaintext email because it did not find an
OPENPGPKEY record? Or an enduser sending an unencrypted email
and not being told by their mail client it could have been
encrypted, and so they send the email in plaintext as they
had planned to originally do anyway?
MUAs start
guessing at mailbox name variations in the way you suggest (or
otherwise),
There is no guessing. See above. See WGLC. See dane archive.
[1] Upon skimming back through the draft, if example.net. owns
an MX record that points to smtp.example.com, it is not
completely clear whether the lookup for an OPENPGPKEY record
should be performed at subdomains of example.net,
smtp.example.com, or example.com.
It is perfectly clear, and does not involve the MX record whatsoever.
The document states:
o The user name (the "left-hand side" of the email address, called
the "local-part" in the mail message format definition [RFC5322]
and the local-part in the specification for internationalized
email [RFC6530]) should already be encoded in UTF-8 (or its subset
ASCII). If it is written in another encoding it should be
converted to UTF-8 and then hashed using the SHA2-256 [RFC5754]
algorithm, with the hash truncated to 28 octets and represented in
its hexadecimal representation, to become the left-most label in
the prepared domain name. Truncation comes from the right-most
octets. This does not include the at symbol ("@") that separates
the left and right sides of the email address.
o The string "_openpgpkey" becomes the second left-most label in the
prepared domain name.
o The domain name (the "right-hand side" of the email address,
called the "domain" in RFC 5322) is appended to the result of step
2 to complete the prepared domain name.
Nowhere does it tell you to look at MX records.
I note in that regard that the first sentence of Section 3 of the
I-D is simply false.
The first sentence reads:
The DNS does not allow the use of all characters that are supported
in the "local-part" of email addresses as defined in [RFC5322] and
[RFC6530].
RFC 6530 Section 7.1:
Permits the use of UTF-8 strings in email addresses, both local
parts and domain names.
So you are claiming that DNS can take any UTF-8 character? I guess you
should file an errata for IDNA RFC-3492.
Paul