I will only talk to the points Eric raised. TL;DR I completely agree with him.
* Who will make the call about what is “urgent”? Is it the TLS WG? The TLS WG is responsible for TLS. I would expect that if anyone came up with a change to TLS, they would be told to go there. I cannot imagine a scenario where this doesn’t happen. * What about extensions that may be required by applications defined in other WGs? There are only two types of extensions that have EVER needed to be defined by other entities, and they are exempted from the freeze. I don’t know how to respond to a PDF ballot. Is that even legit? Is it legit for me to not respond? From: Eric Rescorla <e...@rtfm.com> Date: Monday, March 24, 2025 at 9:12 AM To: Mohamed Boucadair <mohamed.boucad...@orange.com> Cc: The IESG <i...@ietf.org>, draft-ietf-tls-tls12-fro...@ietf.org <draft-ietf-tls-tls12-fro...@ietf.org>, tls-cha...@ietf.org <tls-cha...@ietf.org>, tls@ietf.org <tls@ietf.org> Subject: Re: [TLS] Mohamed Boucadair's Discuss on draft-ietf-tls-tls12-frozen-06: (with DISCUSS and COMMENT) On Mon, Mar 24, 2025 at 12: 37 AM Mohamed Boucadair via Datatracker <noreply@ ietf. org> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-tls12-frozen-06: Discuss When responding, please keep the subject ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd On Mon, Mar 24, 2025 at 12:37 AM Mohamed Boucadair via Datatracker <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-tls12-frozen-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!GjvTz_vk!WMHa5J_W7skBqI9TEsrK0qtclFRr9Ogs6Hi0rgqSb_GA95Eeg3ttpAHIWo3jTZw_D2I38A$> for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/__;!!GjvTz_vk!WMHa5J_W7skBqI9TEsrK0qtclFRr9Ogs6Hi0rgqSb_GA95Eeg3ttpAHIWo3jTZz69LHanw$> ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Hi Rich, Thank you for the effort put in this effort. Thanks to Jen Linkova for the opsdir review. I understood that her comment will be fixed. I’m supportive of this work. I will be balloting “Yes” after the DISCUSS point is addressed. ## On urgent security conditions CURRENT: This document specifies that outside of urgent security fixes, and the exceptions listed in Section 4, no changes will be approved for TLS 1.2. Who will make the call about what is “urgent”? Is it the TLS WG? As a threshold matter, I would think yes. I.e., the TLS WG is responsible for any such security fixes, so just like any change to core TLS, I would expect that the TLS WG should determine acceptability, subject to IETF consensus on eventual publication if the TLS WG did decide to take it on. Else? What about extensions that may be required by applications defined in other WGs? I read this document as prohibiting other WGs from defining such extensions outside of the parameters specified here. -Ekr ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- FWIW, my full review can be found at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.pdf<https://urldefense.com/v3/__https:/github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev*20Med.pdf__;JQ!!GjvTz_vk!WMHa5J_W7skBqI9TEsrK0qtclFRr9Ogs6Hi0rgqSb_GA95Eeg3ttpAHIWo3jTZyWgePgJw$> * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.doc<https://urldefense.com/v3/__https:/github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev*20Med.doc__;JQ!!GjvTz_vk!WMHa5J_W7skBqI9TEsrK0qtclFRr9Ogs6Hi0rgqSb_GA95Eeg3ttpAHIWo3jTZxQ2Ip5ng$> Only a subset of items are echoed here. The author can refer to the full review for nits/edits/etc. # Abstract ## Reword for better clarity OLD: Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. NEW: Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. ## I think “for TLS 1.2-only” would be more accurate as some of these are applicable to TLS1.3 as well. Consider updating accordingly: CURRENT: This document specifies that except urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. # Introduction ## Reword for better clarity OLD: Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. NEW: Both TLS versions have several extension points. Items such as new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. As a side note on “etc.”, I’d like to check if we should be more explicit here given that we have notes in the registry such as: “Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.” # Section 2 ## Provider examples of “huge impact” mentioned in this text: CURRENT: Cryptographically relevant quantum computers, once available, will have a huge impact on RSA, FFDH, and ECC which are currently used in TLS. ## On the various NIST citations: Are there any other similar pointers to list for non-US regions? # Section 4: ## I think the IANA registries should be authoritative here, not the RFC. CURRENT: No registries [TLS13REG] are being closed by this document. ## Call out this is about TLS registries: OLD: No registries [TLS13REG] are being closed by this document. NEW: No registries in TLS registry groups [REF] are being closed by this document. ## Not any random registry, but TLS: OLD: Any registries created after this document is approved for publication should indicate whether the actions defined here are applicable. NEW: Any TLS registry created after this document is approved for publication should indicate whether the actions defined here are applicable. _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
