On Fri, Sep 11, 2015 at 11:53:59AM -0400, John C Klensin wrote:
(1) A delivery server at smtp.example.com, for whatever reason,
associates joesmith(_at_)smtp(_dot_)example(_dot_)com and
JoeSmith(_at_)smtp(_dot_)example(_dot_)com 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(_at_)example(_dot_)net [1].
End-to-end encryption aside, messages are often misaddressed by
users even for addresses a lot less similar than the proposed
example. Sometimes with extreme consequences. I recall one example
where a confidential message intended for a lawyer was sent his
brother the journalist...
I don't think that this draft materially changes the landscape.
Messages in transit should not be modified by relays. Sites that
implement publication of keys should avoid overly similar names,
and would be wise to avoid names that differ only in their case.
In short, I think this objection is not a particularly strong one.
My concerns with the draft are elsewhere.
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.
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.
The DNS is a mechanism for publishing data. That data can include
name to key bindings as appropriate. The security of such bindings
is not unreasonably weak by comparison with other plausible large
scale approaches.
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 vulnerability and risks associated with this approach.
All I'm saying is that deployments of cryptography for the masses
(e.g. iMessage which is under the microscope lately) have been
successful largely by focusing on usability first at some tradeoff
against absolute security assurance, but the tradeoffs can be quite
sensible.
In the case of this draft, we have a metadata leakage problem (sans
DPRIV). We also have a directory harvesting problem because queries
are typically intermediated by caching resolvers are difficult to
rate limit. Finally, we have resolver cache pressure, because
now instead of just the hosts for each domain, resolvers will have
(mostly negative) cache entries for the users of various domains.
And of course "+extension" and other variants are out of scope.
So I have my concerns, they are just mostly different from the ones
you emphasized.
I was initially optimistic about Keith Moore's addrquery draft,
and still hold some hope for that, be he seems to think that security
for the masses needs to be as strong as covert agent security, and
we've had rather a long debate on the UTA list that stands unresolved.
In the mean time he may have run out of cycles to push another
draft revision. So we'll see how that evolves.
--
Viktor.