On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <fen...@bluepopcorn.net> wrote:
> On 2/27/19 2:10 PM, Eric Rescorla wrote: > > > > On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <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. > Yes. 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." > and "if you recognize this indicator, you should fail if the server doesn't do TLS", right? Just like HSTS. 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. > Yes, this is the situation with HSTS as well. > 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. > Yes, what I am saying is that it's not solely the sender's decision, and that this is an indicator that privileges the sender's choice of nonsecurity over the recipient's; of security. Now, arguably, this is a weakness in the semantics of MTA-STS and DANE in that they could have three states: insecure OK, secure only, and secure only unless the sender explicitly says OK, But that's not how they are designed. > > 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. > A Dolev-Yao/3552 network attacker that controls the entire network. 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. > Suppose that you are example.com and you want to ensure that anyone who sends to you uses TLS. Rejecting non-TLS connections doesn't work because unless the sender enforces TLS, the attacker will just impersonate you, refuse to negotiate TLS, and then re-connect to you offering TLS. 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? See above. The enforcement has to be on the client, just as with HSTS. -Ekr -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
