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

[Jim Fenton <[e-mail]>]

On 2/27/19 2:10 PM, Eric Rescorla wrote:
>
>
> On Tue, Feb 26, 2019 at 3:37 PM Jim Fenton <[e-mail]
> <mailto:[e-mail]>> 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