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

["Brotman, Alexander" <[e-mail]>]

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 <[e-mail]> On Behalf Of Jim Fenton
Sent: Wednesday, March 27, 2019 4:34 AM
To: [e-mail]
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