[TLS] Re: Mike Bishop's No Objection on draft-ietf-tls-rfc8446bis-12: (with COMMENT)

[Eric Rescorla <[e-mail]>]

On Mon, Jun 2, 2025 at 10:49 AM Mike Bishop <[e-mail]> 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-mail]>
> *Sent:* Monday, June 2, 2025 11:35 AM
> *To:* Mike Bishop <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>
> *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 <[e-mail]> 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-mail]>
> *Sent:* Friday, May 30, 2025 10:54 AM
> *To:* Mike Bishop <[e-mail]>
> *Cc:* The IESG <[e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <
> [e-mail]>; [e-mail] <[e-mail]>; [e-mail] <
> [e-mail]>
> *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.
>
>