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 > > Sr. Engineer, Anti-Abuse & Messaging Policy > > Comcast > > > > *From:*Jim Fenton <fen...@bluepopcorn.net> > *Sent:* Thursday, March 28, 2019 9:57 AM > *To:* Brotman, Alexander <alexander_brot...@cable.comcast.com>; > uta@ietf.org > *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, > > > > 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> <mailto:uta-boun...@ietf.org> > *On Behalf Of * Jim Fenton > *Sent:* Wednesday, March 27, 2019 4:34 AM > *To:* uta@ietf.org <mailto: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
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
