Subject: Re: [Uta] Revised wording on security consideration re TLS-Required

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 30 Mar 2019 13:44:59 -0500

[sorry about the broekn threading; I get uta@ in digest form and can't dig
out a proper message-id ATM from the archives]

On Wed, Mar 27, 2019 at 12:00:16PM -0700, [email-masked] wrote:
> Date: Wed, 27 Mar 2019 09:34:14 +0100
> From: Jim Fenton <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [Uta] Revised wording on security consideration re TLS-Required
> 
> Thanks for the feedback on my proposed language for a new security
> consideration regarding conflicts between the TLS-Required header field
> and DANE and MTA-STS recipient policies. Here's another stab at it:
> 
> =====
> 
> 8.4. Policy Conflicts
> 
> 
> In some cases, the use of the TLS-Required header field may conflict
> with a recipient domain policy expressed through the DANE [RFC7672] or
> MTA-STS [RFC8461] protocols. Although these protocols encourage the use
> of TLS transport by advertising availability of TLS, the use of
> ”TLS-Required: No” header field represents an explicit decision on the
> part of the sender not to require the use of TLS, such as to overcome a
> configuration error. The recipient domain has the ultimate ability to
> require TLS by not accepting messages when STARTTLS has not been
> negotiated; otherwise, "TLS-Required: No" is effectively directing the
> client MTA to behave as if it does not support DANE nor MTA-STS.
> 
> 
> =====
> 
> 
> Comments welcome.

This doesn't really say anything about or give guidance to intermediate
MTAs.  (Do we want to differentiate between initial and intermediate MTAs,
too?)

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 30 Mar 2019 15:05:24 -0400

> On Mar 30, 2019, at 2:44 PM, Benjamin Kaduk <[email-masked]> wrote:
> 

Essentially, all MTAs are intermediate MTAs.  The header is added to the
message via the sender's *MUA*, and conveys the same sender preference to
every SMTP relay (MTA) en-route.  For this header to be effective at
achieving its goal, there needs to be no prior difference between the MSA's
first relay hop and further downstream relays.  TLS-related delivery issues
can occur at any hop along the path from sender to recipient.

The header does obligate every en-route MTA to ignore its local policy.
Where such local policy mandates TLS, it will likely trump the header.
Where the MTA has no explicit policy and would otherwise follow the
hints (DANE or MTA-STS) from the next-hop destination, the header should
generally allow delivery when operational errors would otherwise break
such delivery by promising and not delivering on the requirements of DANE
or MTA-STS.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 30 Mar 2019 16:01:23 -0400

Oops, second paragraph should read: The header does *not* ...

> On Mar 30, 2019, at 3:05 PM, Viktor Dukhovni <[email-masked]> wrote:
> 

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Sat, 30 Mar 2019 22:06:19 +0100

> MTAs.  (Do we want to differentiate between initial and intermediate MTAs,

Part of the reason for using the term "client MTA" is that it's
inclusive of initial and intermediate MTAs; we don't want to differentiate.

-Jim