On Tue, Mar 25, 2025 at 6:26 AM Salz, Rich <rsalz= 40akamai....@dmarc.ietf.org> wrote:
> 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. > Indeed. I don't really see how more precise language would be helpful here, as the WG would still need to approve each proposed change anyway. -Ekr > ## 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}} > > > > _______________________________________________ > 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
