Hi Rich, Ekr, all, Thanks for the follow-up and clarification.
I think that I had the discussion I wanted to have. I will clear my DISCUSS. Rich, the proposed changes to the comments part look good to me. One nit though, s/lesssen the time/lessen the time. Cheers, Med De : Salz, Rich <rs...@akamai.com> Envoyé : mardi 25 mars 2025 14:26 À : 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 Objet : Re: Mohamed Boucadair's Discuss on draft-ietf-tls-tls12-frozen-06: (with DISCUSS and COMMENT) The formatting is really messed up here. I will preface my inline comments with "R$ 25-Mar" I removed the points where we agree (mainly I changed the text and you approved it :) 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. R$ 25-Mar: I understand that urgent is not a precise term, but I cannot think of anything better and to me it accurately conveys the situation. The WG really does not want to ever look at TLS 1.2 again but we have to leave open the possibility that it might happen. I am open to suggestions to change, but expect that the WG would have to approve it. ## 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. R$ 25-Mar: No. Even if it is possible to use an extension for TLS 1.2, we want to make it very clear that people should not expect it to show up in their TLS 1.2 libraries. # Section 2 ## Provider examples of "huge impact" mentioned in this text: , and the like. Doing this would muddy the waters for the clear statement we want to make. [Med] Alternatively, you may simply say "be powerful enough to break conventional cryptographic systems, such as RSA, FFDH, and ECC". R$ 25-Mar: how about this: "Cryptographically relevant quantum computers, once available, are likely to greatly lesssen the time and effort needed to break RSA, FFDH, or ECC which are currently used in TLS." ## 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 kkkkSafe schemes<https://urldefense.com/v3/__https:/www.etsi.org/deliver/etsi_tr/103600_103699/103619/01.01.01_60/tr_103619v010101p.pdf__;!!GjvTz_vk!RUNQyWdWUylYLlrfk9yyOWhu0xYrHkwQWos4aQegUZL-imLU3tjD-ikQJUibOd019hkxzGlftglyXXbWozN3SY6h$>) or the latest UK plan (https://www.ncsc.gov.uk/guidance/pqc-migration-timelines<https://urldefense.com/v3/__https:/www.ncsc.gov.uk/guidance/pqc-migration-timelines__;!!GjvTz_vk!RUNQyWdWUylYLlrfk9yyOWhu0xYrHkwQWos4aQegUZL-imLU3tjD-ikQJUibOd019hkxzGlftglyXXbWo6VDWo-A$>)). R$ 25-Mar: I added a point to ETSI: In 2024 NIST released standards for {{ML-KEM}}, {{ML-DSA}}, and {{SLH-DSA}}. Many other countries and organizations are publishing their roadmaps, including the multi-national standards organization ETSI, {{?ETSI}} ____________________________________________________________________________________________________________ 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
