On Mon, Mar 24, 2025 at 12:37 AM Mohamed Boucadair via Datatracker < 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/ > 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/ > > > > ---------------------------------------------------------------------- > 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 > * doc: > > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.doc > > 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 > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
