On Mon, Jun 2, 2025 at 10:49 AM Mike Bishop <mbis...@evequefou.be> wrote:
> 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). > Well, all of these deprecation RFCs are sort of like that, unfortunately. > > 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. > Thanks. I'm inclined not to make any changes, but let's see what the WG and the ADs say. -Ekr > ------------------------------ > *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> 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> > *Sent:* Friday, May 30, 2025 10:54 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) > > 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
