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

[Jim Fenton <[e-mail]>]

On 2/28/19 9:42 AM, Eric Rescorla wrote:
>
>
> On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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.
>
>
> 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