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

[Eric Rescorla <[e-mail]>]

We had a bunch more discussion on this on the IESG call. It seems like
the primary use case for TLS-Required=no may be to exempt what's basically
the control channel from the requirement to use TLS. So, for instance,
I am getting persistent bounces from you and I want to notify you
about it, so I send that notification with the TLS-Required=no flag set
[0].

Assuming that's right, then ISTM that actually this is not the ideal
design, both because it's not clear how the flag gets set and because
the recipient has had no chance to weigh in. What I would suggest would
instead be to extend MTA-STS and DANE to exempt specific "control"
addresses (e.g., Postmaster) from mandatory TLS. This seems like it
would solve the main problem while avoiding opening the can of
users just marking routine messages as non-sensitive.

-Ekr


[0] In some unspecified way? Perhaps a button in the MUA UI?


On Wed, Mar 13, 2019 at 2:55 PM Eric Rescorla <[e-mail]> wrote:

>
>
> On Wed, Mar 13, 2019 at 2:49 PM Viktor Dukhovni <[e-mail]>
> wrote:
>
>> > On Mar 13, 2019, at 5:13 PM, Eric Rescorla <[e-mail]> wrote:
>> >
>> > Well, I think this field should only override the outgoing and not
>> incoming policies (or be removed).
>>
>> To be clear, let's imagine a company (say a bank) with the following TLS
>> policies (written roughly Postfix-style, but should be clear even to the
>> uninitiated):
>>
>>         # Mandatory PKIX authenticated TLS with back office settlement
>> business partner,
>>         # And mutually agreed set of CAs.
>>         #
>>         partner.example         secure tafile=partner-cas.pem
>> match=mx.partner.example
>>
>>         # Mandatory DANE-TLS with another business partner known to
>> support DANE
>>         #
>>         partner2.example        dane-only
>>
>>         # Opportunistic DANE TLS when available with general-purpose email
>>         # (In real life the global default would be specified elsewhere)
>>         *                       dane
>>
>> I think you're saying that the company could allow its users to bypass
>> the locally-policy business partner domain rules, but must refuse to
>> allow users to exempt casual correspondence from DANE (or MTA-STS)
>> policy when published by the destination domain.
>>
>> Is that right?
>>
>
> Yes.
>
> -Ekr
>
>
>> --
>> --
>>         Viktor.
>>
>>