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

[Paul Wouters <[e-mail]>]

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, "[e-mail]" 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 "[e-mail]" to "[e-mail]"
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 [e-mail] and [e-mail]

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