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

From: Jim Fenton <[email-masked]>
Date: Wed, 27 Mar 2019 09:34:14 +0100

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.

-Jim

---

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 28 Mar 2019 13:51:55 +0000

Jim,

I’m not sure how much of an impact this might have, but should there be a reference to TLSRPT?  Either not to be counted or to explain the lack of TLS based on “TLS-Required: no” being set?

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

From: Uta <[email-masked]> On Behalf Of Jim Fenton
Sent: Wednesday, March 27, 2019 4:34 AM
To: [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.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Mar 2019 14:57:15 +0100

Good thought. Since it's acting as though it doesn't implement MTA-STS,
then it should not include these messages in TLSRPT reports, correct?

On 3/28/19 2:51 PM, Brotman, Alexander wrote:
>
> Jim,
>
>  
>
> I’m not sure how much of an impact this might have, but should there
> be a reference to TLSRPT?  Either not to be counted or to explain the
> lack of TLS based on “TLS-Required: no” being set?
>
>  
>
> --
>
> Alex Brotman
>
> *From:*Uta <[email-masked]> *On Behalf Of *Jim Fenton
> *Sent:* Wednesday, March 27, 2019 4:34 AM
> *To:* [email-masked]
> *Subject:* [Uta] Revised wording on security consideration re TLS-Required
>
>  
>
> 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
>
>  
>
> MTA-STS [RFC8461] protocols. Although these protocols encourage the
> use of TLS transport by advertising availability of TLS, the use of
> 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

---

From: "Brotman, Alexander" <[email-masked]>
Date: Thu, 28 Mar 2019 14:00:27 +0000

Or state that the request to use DANE/MTA-STS was ignored as requested by the sender.  There’s a free-text option for the TLS failure reason, which could perhaps suffice here.  That would allow for a more complete data picture for the receiver of the reports.

From: Jim Fenton <[email-masked]>
Sent: Thursday, March 28, 2019 9:57 AM
To: Brotman, Alexander <[email-masked]>; [email-masked]
Subject: Re: [Uta] Revised wording on security consideration re TLS-Required

Good thought. Since it's acting as though it doesn't implement MTA-STS, then it should not include these messages in TLSRPT reports, correct?
On 3/28/19 2:51 PM, Brotman, Alexander wrote:
Jim,

From: Uta <[email-masked]><mailto:[email-masked]> On Behalf Of Jim Fenton
Sent: Wednesday, March 27, 2019 4:34 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [Uta] Revised wording on security consideration re TLS-Required

=====

8.4. Policy Conflicts

=====

Comments welcome.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 28 Mar 2019 15:36:16 +0100

But then we would want to have a consistent failure reason for this, so
to do this right we would want to add a new entry to the STARTTLS
Validation Result Types registry. Not a free-text entry that could vary
from implementation to implementation.

Wish we had caught this earlier!

On 3/28/19 3:00 PM, Brotman, Alexander wrote:
>
> Or state that the request to use DANE/MTA-STS was ignored as requested
> by the sender.  There’s a free-text option for the TLS failure reason,
> which could perhaps suffice here.  That would allow for a more
> complete data picture for the receiver of the reports.
>
>  
>
> --
>
> Alex Brotman
>
> *From:*Jim Fenton <[email-masked]>
> *Sent:* Thursday, March 28, 2019 9:57 AM
> *To:* Brotman, Alexander <[email-masked]>;
> [email-masked]
> *Subject:* Re: [Uta] Revised wording on security consideration re
> TLS-Required
>
>  
>
> Good thought. Since it's acting as though it doesn't implement
> MTA-STS, then it should not include these messages in TLSRPT reports,
> correct?
>
>     I’m not sure how much of an impact this might have, but should
>     there be a reference to TLSRPT?  Either not to be counted or to
>     explain the lack of TLS based on “TLS-Required: no” being set?
>
>      
>
>     --
>
>     Alex Brotman
>
>     *From:*Uta <[email-masked]> <mailto:[email-masked]>
>     *On Behalf Of * Jim Fenton
>     *To:* [email-masked] <mailto:[email-masked]>
>     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.
>
>      
>
>     -Jim
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta