On 2/27/19 2:10 PM, Eric Rescorla wrote: > > > On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <fen...@bluepopcorn.net > <mailto:fen...@bluepopcorn.net>> wrote: > > On 2/21/19 7:07 AM, Eric Rescorla wrote: > > > ---------------------------------------------------------------------- > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > I support Benjamin's DISCUSS. > > > > 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 > > > The general approach of REQUIRETLS is that the sender is in a good > position to determine the sensitivity of the message(s) they are > sending, because they know what the message is. > > > Right, this is what I am disputing.
If I'm reading this correctly, you're concerned about the header field (don't require TLS even if recipient domain policy says to) rather than concerned about the REQUIRETLS SMTP extension requiring the use of TLS. Let me know if this is incorrect. The preferences we're talking about here (MTA-STS and DANE) are basically advertisements saying, "if you send mail to this domain, you should expect to use TLS when doing so." There will always be SMTP clients that don't implement MTA-STS and DANE (and possibly even STARTTLS) and will behave exactly as they do today. You described it correctly as a preference; if the sender wants to emphasize delivery over security, they can ignore that preference. That's basically what the header field (RequireTLS: no or perhaps TLS-Required: no) does. > > > Ultimately, for the last > hop anyway, the recipient has the ultimate control: they can refuse to > accept a message unless STARTTLS has been negotiated. > > > Actually, this doesn't work for two reasons: > > 1. There might be an active attacker. Please elaborate on the type of active attacker you are referring to. An impostor SMTP server? Note that either DNSSEC or MTA-STS is required in the secure (SMTP extension) case in order to guard against forged MX records. > 2. Requiring TLS on the *receiver* side means that you can't talk to > clients which don't speak TLS. I probably should have labeled it as a non-serious idea. But if the concern is that someone might override the domain's preferences that messages be sent via TLS by sending a message without TLS, you can't talk to clients that don't speak TLS, right? -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
