Re: [Uta] Eric Rescorla's Discuss on draft-ietf-uta-smtp-require-tls-07: (with DISCUSS and COMMENT)

[Viktor Dukhovni <[e-mail]>]

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.

When sending domain supports outbound DANE (which is further along
the adoption curve than the more recent MTA-STS) it can (and many
do) implement exception lists to deal with remote misconfiguration,
or to for some other local policy reason.  There is conversely also
some use of local mandatory TLS policy, when neither DANE nor MTA-STS
are available.

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, or to skip either or
both for selected destinations.

Even with MTA-STS or DANE not implemented or disabled, the sender
can still use unauthenticated STARTTLS, or stronger.

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.

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.

Thus, for example, TLSRPT (RFC8460) suggests that reports be sent
even when MTA-STS or DANE fail for the remote destination.

Again, this draft extends the same flexibility to the user, if
supported by the user's MSA and beyond.

-- 
	Viktor.