First, it keeps stating DTLS is excluded from this draft's recommendations but the reasons cited for why this is needed for TLS apply eually to DTLS. So why is DTLS excluded from this? If there are valid reasons, I think the document should at least state these.
DTLS is excluded because DTLS 1.3 is not generally available nor deployed; both OpenSSL and BoringSSL are writing code now. Happy to add the first part of the previous sentence. Second point is the text about NIST: In 2016, the US National Institute of Standards and Technology (NIST) started a multi-year effort to standardize algorithms that will be "safe" once quantum computers are feasible [PQC<https://urldefense.com/v3/__https:/csrc.nist.gov/projects/post-quantum-cryptography__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvutxrz98$>]. The first IETF discussions happened around the same time [CFRGSLIDES<https://urldefense.com/v3/__https:/www.ietf.org/proceedings/95/slides/slides-95-cfrg-4.pdf__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvnqMCzE5$>].In 2024 NIST released standards for [ML-KEM<https://urldefense.com/v3/__https:/csrc.nist.gov/pubs/fips/203/final__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvvSZeAgn$>], [ML-DSA<https://urldefense.com/v3/__https:/csrc.nist.gov/pubs/fips/204/final__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvqWYtohE$>], and [SLH-DSA<https://urldefense.com/v3/__https:/csrc.nist.gov/pubs/fips/205/final__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvtRZ-1iY$>]. While industry was waiting for NIST to finish standardization, the IETF has had several efforts underway. A working group was formed in early 2023 to work on operational and transitional uses of PQC in IETF protocols, [PQUIPWG<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/pquip/about/__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvtkkwYWf$>]. Several other working groups, including LAMPS [LAMPSWG<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/lamps/about/__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvqyjIfg9$>], TLS [TLSWG<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/tls/about/__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvpvU55RC$>], and IPSECME [IPSECMEWG<https://urldefense.com/v3/__https:/datatracker.ietf.org/wg/ipsecme/about/__;!!GjvTz_vk!RMPR4QNH_dFLCvmMNj_jsnvtBapHPJze_lNGqprKjXkbR1JhKV0FTCCRgKgG2YFz95pSC0k7NQS1bzE9ElRjvixWTDgj$>], are working on drafts to support hybrid algorithms and identifiers, for use during a transition from classic to a post-quantum world. I don't see the relevance of this bit of history. I do see that this point might be contentious for some people who feel IETF is "subservient" to NIST. I would propose to remove it, or at most keep the latter bit in a slightly reworded way. I also feel the clear distinction between pure (by NIST) and hybrid (by IETF) is lost a bit, but rather than fixing that, I'd just favour removing all the text. That’s fine with me as long as the WG has no issues with it.
_______________________________________________ Uta mailing list -- uta@ietf.org To unsubscribe send an email to uta-le...@ietf.org
