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@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]. 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.