Hi Rich, Thanks for the follow-up.
Please see inline. Cheers, Med De : Salz, Rich <rs...@akamai.com> Envoyé : lundi 24 mars 2025 19:27 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; The IESG <i...@ietf.org> Cc : draft-ietf-tls-tls12-fro...@ietf.org; tls-cha...@ietf.org; tls@ietf.org; s...@sn3rd.com Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-tls-tls12-frozen-06: (with DISCUSS and COMMENT) Thanks for the detailed review. Comments inline below. ## 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? Else? What about extensions that may be required by applications defined in other WGs? A separate sub-thread (from EKR and me) says: yes, just TLS WG. Who else is chartered to do so? :) As for other WG extensions, the only ones that have *EVER* come up are exempted ALPN and exporters. [Med] I suspected that from a process perspective ;-) I'm actually approaching this from an ops perspective, where a fix can be judged as urgent by those who actually deploy (have legacy deployments), while TLS WG may tell them to migrate to TLS 1.3. In order to avoid disconnects about how that is supposed to work, I'd like we better characterize "urgent security fixes". Thanks. # 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. Yes, fixed thanks. [Med] Thanks ## 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. I do not understand this comment. If you mean a new extension is added that *would* be usable in TLS 1.2, we're saying that it is not defined for TLS 1.2 even if it would "just work." Is that your point? [Med] Some extensions may be applicable independent of the version. I think that it is more accurate: s/no changes will be approved for TLS 1.2/ no changes will be approved for 'TLS 1.2'-only. # 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. Changed, thanks. [Med] ACK 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." I think that is a confusing level of detail for this document. Except for cipher suites the other registry values are used unchanged. [Med] Thanks. # 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. I would rather not do so, because I want to avoid explaining Shor's algorithm, factoring vs the discrete log problem, and the like. Doing this would muddy the waters for the clear statement we want to make. [Med] That's fair, but the mention of "huge impact" can be clarified by adding a pointer to Section 2 of draft-ietf-pquip-pqc-engineers. Alternatively, you may simply say "be powerful enough to break conventional cryptographic systems, such as RSA, FFDH, and ECC". ## On the various NIST citations: Are there any other similar pointers to list for non-US regions? There does not seem to be. At a recent IETF side meeting, several countries said "we're following the NIST algorithms." As that is the only standard published so far, it seems okay. [Med] ACK for the algo part. Maybe this can be balanced by briefly citing the migration roadmap announced by non-US countries (e.g., ETSI (TR 103 619 - V1.1.1 - CYBER; Migration strategies and recommendations to Quantum Safe schemes<https://www.etsi.org/deliver/etsi_tr/103600_103699/103619/01.01.01_60/tr_103619v010101p.pdf>) or the latest UK plan (https://www.ncsc.gov.uk/guidance/pqc-migration-timelines)). # Section 4: ## I think the IANA registries should be authoritative here, not the RFC. CURRENT: No registries [TLS13REG] are being closed by this document. This wording came from discussions with IANA about what to say. [Med] All is good then. ## 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. I will change to "No TLS registries ..." [Med] Thanks. ## 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. The whole document is about TLS registries, but sure. [Med] ACK ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
