Victor,
Your message contains a long chain of suppositions. I really
don't have time to do, and write, a complete analysis, but I
think the most essential issues are covered below...
--On Friday, September 11, 2015 14:44 +0000 Viktor Dukhovni
<ietf-dane@xxxxxxxxxxxx> wrote:
> On Fri, Sep 11, 2015 at 02:43:59AM -0400, John C Klensin wrote:
>
>> (2) If the use of this approach leads to violations of 5321
>> (as both John L. and I believe it does) or could have other
>> side effects on the use and operation of the mail system,
>> then the I-D should have an evaluation of those cases and bow
>> any damage can be mitigated both during the experiment and in
>> any possible production follow-up. If the WG expects the
>> latter to emerge during the experimental period, that should
>> be explicit and the experimental evaluation should conclude
>> the effort was a failure if that does not occur.
>
> Note, I am ambivalent as to whether the draft represents a
> sound long-term approach to publishing user keys in DNS.
>
> However, I should note that I take 5321 to apply primarily once
> messages enter the email transport system. At the point of
> message composition, when a user is interactively composing an
> email, if the MUA allows the user to try a case invariant of
> the address (particularly on devices that gratuitously
> capitalize the first letter of entered text) that I think is
> outside the scope of 5321 which keeps relays from damaging
> messages already in transit.
>
> Trying a lower-case variant is something an MUA supporting the
> draft would do to help a user find the right key. This does
> not introduce damage of message envelopes for mail in transit.
Certainly you are correct about messages in transit. Noting
that SMTP requires that case variations in the local-part be
preserved even while it discourages taking advantage of them
(see Section 2.4 of RFC 5321), consider the following:
(1) A delivery server at smtp.example.com, for whatever reason,
associates joesmith@xxxxxxxxxxxxxxxx and
JoeSmith@xxxxxxxxxxxxxxxx with different mailboxes. That policy
might be thoroughly hidden from users, e.g., by the latter
address never being advertised but reached via an MX record for
example.net, i.e., the address JoeSmith@xxxxxxxxxxx [1].
(2) The owner of the joesmith mailbox chooses to supply a
OPENPGPKEY DNS RR and key, the owner of the JoeSmith one chooses
to not do so.
(3) Your MUA tries to look up an OPENPGPKEY record associated
with [2] JoeSmith and gets a failure. It then decides to
lower-case the string, looks for a key associated with joesmith,
and gets one. This is an instance of what John Levine and I
have referred to as "name guessing" or "address guessing" and
results in a false positive for the key for JoeSmith. If one is
lucky, the message is then sent to JoeSmith encrypted in the key
for joesmith. Since the owner of the JoeSmith mailbox doesn't
have the joesmith private key (and absent MITM or other attacks
on intermediates), the message will arrive but not be able to be
decrypted and no important information is disclosed (I note that
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.
I believe that whole scenario is a bad idea and is one of
several reasons why originating MUAs should not start
algorithmically guessing at names --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. Either way,
the draft is not ready for publication; sufficiently unready
that I believe it should never have been posted for IETF Last
Call.
> So I think the main objection is not that a variant
> (lower-case) might be tried, but that there's no way to find
> all the right variants to try (e.g. +extensions, especially
> since even the "+" is a destination-dependent character).
> This means that a user who wants to receive end-to-end
> encrypted email for a set of distinct addresses that are all
> mapped to the same mailbox would need to publish multiple
> public key bindings.
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
represent the same or different mailboxes and, if different,
whether they represent the same or different users. That raises
a separate issue which is that, while we often use mailbox
identifiers to identify keys, users are not, and never have
been, uniquely bound to mailboxes.
> One might note that with both PGP and S/MIME, the public key
> binding is via a "certificate" that also includes the user's
> address.
While some PGP traditionalists would, I believe, object to the
use of the term "certificate", what they include is a mailbox
address that is more or less "certified" as belonging to the
user. Whether or not it is "the user's address", is another
matter. 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.
>...
> 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.
> We've long ago learned that scaling secure communications to
> the masses means giving up absolute end-to-end assurance.
> Usable encryption for the masses will not be as strong as
> tailor-made encryption for covert agents.
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.
>...
> This could make scaling less of an issue, because adoption
> rates are likely to be rather low, I don't expect any large
> provider to enroll all but a tiny fraction of their users in
> the foreseeable future.
However, as illustrated by the example above, if a given domain
"enrolls" some of its mailboxes but not others, and MUAs start
guessing at mailbox name variations in the way you suggest (or
otherwise), the vunerability to false positives increases.
Again, I expect that to be discussed in the Security
Considerations section and believe that normal IETF rules for
those sections requires such a discussion.
>...
john
[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. The question becomes more
complex if example.net is associated with multiple MX RRs whose
data identifies different domains. The I-D should be explicit
about this unless name guessing is expected for those cases too,
in which case even more is needed in Security Considerations.
[2] I say "associated" because of concerns about the proposed
hashing mechanisms (which John Levine identified as well)
including the possibility of false positives there as well. I
note in that regard that the first sentence of Section 3 of the
I-D is simply false. The authors and advocates of this draft
might find it helpful to read RFC 2181, 1034, and 1123 (not
necessarily in that order).