On 2/28/19 9:42 AM, Eric Rescorla wrote: > > > On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <fen...@bluepopcorn.net > <mailto: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 <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. > > > 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.
That's right, "secure only" is not the semantics of MTA-STS and DANE. So TLS-Required: no is consistent with those semantics. It might be interesting to see how MTA-STS and DANE could be extended to have the other states, but the lack of those states is outside the scope of TLS-Required: no. > > >> >> 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 <http://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. Since MTA-STS and DANE do not have a "secure only" state, this is outside the threat model of those protocols. Adding requirements to clients implementing TLS-Required (such as that they check for MTA-STS and DANE [and in turn implement DNSSEC]) doesn't do anything about the bigger problem with clients who don't implement TLS-Required. -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
