On Thu, Feb 28, 2019 at 10:36 AM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Thu, Feb 28, 2019 at 09:42:31AM -0800, Eric Rescorla wrote: > > > > 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. > > Thanks for the clarification, I now see how you're arriving at your > position. The key difference is that you see MTA-STS and DANE as > analogous to HSTS in setting a mandatory security policy for the > client. But the analogy is crucially imperfect. > > * With browsers, given an "http://"; URL or bare domain in the > browser's address bar, the client either honours that and uses > an unauthenticated, unencrypted channel, or given HSTS > unconditionally upgrades to encrypted authenticated HTTPS. > > * With SMTP, there isn't a second email address format for email > delivery over TLS. The MTA chooses the best available security > level opportunistically. The baseline is cleartext delivery. > > * SMTP upgrades to (unauthenticated) STARTTLS opportunistically, > when offered by the peer. Even in the absence of DANE, MTA-STS, > etc., the sender can and most often does use STARTTLS (~92% > of the time in/out of Gmail). Which is sufficient to deal > with passive monitoring. > > * But active attacks can forge MX replies, strip STARTTLS or > MiTM the TLS session. > > * What DANE and MTA-STS (after first contact) do is harden the > peer signal against active attack, *enabling* the sending system > to negotiate the highest shared security level. > > * Neither *obligates* the sending system to use them without > exceptions. > > * This is in part because even without either, STARTTLS is then > typically used, and is often viewed as an adequate compromise > between security and reliabile delivery. > I'm sorry, but I don't see how any of this is meaningfully different from the situation with HSTS. In both cases, the receiving system indicates that the sending system ought to use secure transport, and if the sending system conforms to the specification providing that indication, it is required to use secure transport. See: https://tools.ietf.org/html/rfc8461#section-5 " When sending to an MX at a domain for which the sender has a valid, non-expired MTA-STS Policy, a Sending MTA honoring MTA-STS applies the result of a policy validation failure in one of two ways, depending on the value of the policy "mode" field: 1. "enforce": In this mode, Sending MTAs MUST NOT deliver the message to hosts that fail MX matching or certificate validation or that do not support STARTTLS." DANE and MTA-STS describe what a sender must do *when* doing DANE > or MTA-STS, in order to get a result that is (more) resistant to > active downgrade attacks, but they are not mandates. The sender > can elect to not implement either or both, This seems to be precisely the situation with HSTS. Clients are not obligated to implement HSTS. > or to skip either or > both for selected destinations. > I actually don't see this text in 8461. Can you supply a link? All that this draft does is specify a way for the sending system > to give the user some control over the handling of his message, > so that MUAs and downstream relays can recognize the user's > preference and perhaps take it into account. That's one read of it, but another is that it allows the sender to instruct the intermediary to override the receiver's clearly expressed preferences. We should keep in mind that email is often the medium used to > communicate about operational failures. And that not infrequently, > insecure email is the medium through which more essential security > is brought back into service elsewhere. > Well, this seems like potentially an argument that MTA-STS is a bad idea, but it's not clear to me that this document is the appropriate fix, for the reasons I indicate above. -Ekr
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
