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

[Jim Fenton <[e-mail]>]

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
>
> 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
>