From a real-world perspective, I agree — if servers choose to negotiate deprecated protocols, they should at least use the anti-downgrade mechanisms we've built. In terms of spec consistency, it feels very odd to have 2119 requirements that only apply if you choose to violate the requirements we've already stated. So it's a 6919-esque MUST NOT (BUT WE KNOW YOU WILL).
RFC8996 acknowledges that there will be a delay between publication of the BCP and implementation of the deprecation in the real world; "Adopting the practices recommended by this document for any systems that need to communicate with the aforementioned class of systems will cause failure to interoperate. [Consider the trade-off] when deciding how quickly to adopt the recommendations specified in this document." I can certainly understand making a similar acknowledgement here, but perhaps stronger language warning such implementations that they're straying off the beaten path is useful. Regardless, this is a non-blocking comment, and I'll defer to you, the WG, and the responsible AD on exactly how to balance this. ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Monday, June 2, 2025 11:35 AM To: Mike Bishop <mbis...@evequefou.be> Cc: The IESG <i...@ietf.org>; draft-ietf-tls-rfc8446...@ietf.org <draft-ietf-tls-rfc8446...@ietf.org>; tls-cha...@ietf.org <tls-cha...@ietf.org>; tls@ietf.org <tls@ietf.org>; s...@sn3rd.com <s...@sn3rd.com> Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT) Thanks. It might help to start with some background. While it's true that the IETF has deprecated TLS versions prior to TLS 1.2, we also know that there are many sites which support TLS 1.0 and TLS 1.1. [0] We would still like those implementations to perform anti-downgrade, despite violating this other MUST. So, I don't think that treating this as a historical requirement is the right answer. -Ekr [0] https://www.ssllabs.com/ssl-pulse/ On Mon, Jun 2, 2025 at 7:40 AM Mike Bishop <mbis...@evequefou.be<mailto:mbis...@evequefou.be>> wrote: Sorry, I should have quoted it. It's https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#section-4.1.3-11 in the editor's copy: [RFC8996<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#RFC8996>] and Appendix E.5<https://tlswg.org/tls13-spec/draft-ietf-tls-rfc8446bis.html#backward-compatibility-security> forbid the negotiation of TLS versions below 1.2. However, server implementations which do not follow that guidance MUST set the last 8 bytes of their ServerHello.random value to the bytes: 44 4F 57 4E 47 52 44 00 Appendix E.5 states that versions below 1.2 "MUST NOT be negotiated for any reason," yet this text then has a MUST-level requirement applying exclusively to server implementations which ignore the MUST NOT. ________________________________ From: Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> Sent: Friday, May 30, 2025 10:54 AM To: Mike Bishop <mbis...@evequefou.be<mailto:mbis...@evequefou.be>> Cc: The IESG <i...@ietf.org<mailto:i...@ietf.org>>; draft-ietf-tls-rfc8446...@ietf.org<mailto:draft-ietf-tls-rfc8446...@ietf.org> <draft-ietf-tls-rfc8446...@ietf.org<mailto:draft-ietf-tls-rfc8446...@ietf.org>>; tls-cha...@ietf.org<mailto:tls-cha...@ietf.org> <tls-cha...@ietf.org<mailto:tls-cha...@ietf.org>>; tls@ietf.org<mailto:tls@ietf.org> <tls@ietf.org<mailto:tls@ietf.org>>; s...@sn3rd.com<mailto:s...@sn3rd.com> <s...@sn3rd.com<mailto:s...@sn3rd.com>> Subject: Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT) Thank you for comments. I have made a PR to address most of these comments: https://github.com/tlswg/tls13-spec/pull/1385 I am a bit unsure about one comment. Can you point to the offending text for the comment below: The language around the SCSV for pre-1.2 values feels odd. You MUST NOT negotiate older versions, but if you do anyway, you MUST do it this way? I would shift this to a description of how clients and servers were required to behave prior to this revision of 1.3 at most.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
