On Thu, 21 Feb 2019 07:07:09 -0800, Eric Rescorla wrote: > To elaborate on one point a bit: it seems to me that it's harmful to > security to allow the sender to unilaterally override the recipient's > preferences that something be encrypted. To forestall one argument, > yes, the sender knows the contents of the message, but the recipient > knows their own circumstances, and they may be at particular risk > [...]
This is placing too strong an emphasis on security to the detriment of availability. As in all things, we have to make trade-offs, and perfection is not available to us. In particular: - Email to postmaster@domain *must* be able to flow in the face of security-related misconfiguration, full stop. And, it's not always postmaster that is the contact. The actual address of the actual postmaster can come from DNS SOA RRs, web pages, etc... If it were only postmaster@... surely you'd be amenable to exempting that. - Senders own the contents of what they send. Recipients own the contents of what they receive. Each can have different policies as to how it should be sent or received, but each also can post it on social media, newspapers, whatever. Just because one of the parties wishes something be kept confidential, there is no guarantee in the absence of legal, contractual obligations (and PGP or S/MIME, since hop-by-hop transport security might not cut it or even be available). Refusing to accept insecurely-sent messages does not ensure their confidentiality! The recipient does NOT know the sender's circumstances, and I do think the sender's trump the recipient's. HOWEVER, it is fair and *highly* desirable of the recipient to *mark* a message as received insecurely -- keeping in mind that the recipient can't force the sender to have authenticated the recipient... My idea of an ideal end-state for hop-by-hop security for e-mail is that: a) *senders* should be able to specify in the envelope that they want secure, encrypted, authenticated delivery of email at every hop, b) senders should get bounces when that cannot happen, c) *recipients* get an indication of the security of any given e-mail's path to the recipient (perhaps we need a Transmitted: header by which each sending hop MTA can record what it did to authenticate the next hop), d) (a) and (c) get prominent UI indications in MUAs, e) as explained above, *senders* get a "make it go please" button for, e.g., "hey, dear recipient, your mail system is misconfigured, I cannot send secure e-mail" type messages. Lastly, f) forward notifications of failure to meet security policy (sender's or recipient's!), subject to DoS / spam filtering, naturally. A forward notification being like a bounce, but in the other direction. The sender's address, the subject, etc., might not be disclosed -- the important thing is that the recipient should be able to discover misconfigurations and fix them. Nico -- _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
