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

[Eric Rescorla <[e-mail]>]

On Thu, Feb 28, 2019 at 9:33 AM Jim Fenton <[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]> 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.


>
> 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 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.


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?

See above. The enforcement has to be on the client, just as with HSTS.

-Ekr



-Jim