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 <uta-boun...@ietf.org> On Behalf Of Jim Fenton Sent: Wednesday, March 27, 2019 4:34 AM To: uta@ietf.org 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
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
