> On Jul 11, 2023, at 13:52, Salz, Rich <rs...@akamai.com> wrote: > >> This email starts the working group last call for "Deprecating Obsolete Key >> Exchange Methods in TLS 1.2” I-D, located here: > >> . https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex > > Three minor issues and a question. > > Consider saying once, early.in the document, that this does not address TLS > 1.0 and TLS 1.1 as they were already deprecated.
This appears in s2: Note that TLS 1.0 and 1.1 are deprecated by [RFC8996] and TLS 1.3 does not support FFDH [RFC8446]. You’re suggesting that this be moved to s1? > Are the appendices normative? I think so. That should be explicitly stated > in each appendix. Maybe … if the the IANA considerations section stays as is they probably should be. But, see below. > I would shuffle the appendices so that the order is B first (since it > contains NEW information not in the registry) and then A C D. The rationale > is that it puts all registry changes (mark as "not recommended" in one spot). > > The question might be more appropriate for the TLS chairs. About sync'ing > this with the registry changes draft [1]. That document adds a DISCOURAGED > value. Can we put this doc and [1] in the same cluster, so that the > "discourage" use (currently in appendix B) gets reflected into the registries > right away? > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ This I-D doesn’t refer to -rfc8447bis so if we wanted to put them in the same cluster we’d need to get PaulW to add some kind of instruction for the RFC editor. But, we could “fix” that by tweaking the IANA considerations to just provide IANA instructions to IANA for those cipher suites that we are changing in s5 and reference -rfc8447bis. The thing is that some of the suites listed in Appendix C are already “N" so we need to be clearer about what IANA needs to do. Sorting the IANA registry based on the Recommended column Y” and comparing it to what’s in Appendix C, the new changes are: Y-> N 0xCC,0xAA TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 0xCC,0xAD TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 0xC0,0xA7 TLS_DHE_PSK_WITH_AES_256_CCM 0xC0,0xA6 TLS_DHE_PSK_WITH_AES_128_CCM 0xC0,0x9F TLS_DHE_RSA_WITH_AES_256_CCM 0xC0,0x9E TLS_DHE_RSA_WITH_AES_128_CCM 0x00,0xAB TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 0x00,0xAA TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 0x00,0x9F TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 0x00,0x9E TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 N->D All in Appendix B. Did I get that right? If that’s the case then maybe make Appendix B normative (and resort the Appendices), list the Y->N changes above in s5, and leave the rest informative (since they’re already or will be N)? And, we should probably change the name of the Appendices from “XXX Cipher Suites Deprecated by This Document” to “Deprecated XXX Cipher Suites” to not mislead readers that this document did all the deprecation. But, I do like the idea of adding a reference to this document for all the registry entries listed in Appendices - kind of like a tombstone. spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
