> On May 22, 2025, at 3:34 PM, Sean Turner <s...@sn3rd.com> wrote: > > Valery, > > Hi! I pinged the authors about this, but I will weigh in on your 1st issue > below and one of the comments. > >> On Apr 17, 2025, at 4:47 AM, Valery Smyslov via Datatracker >> <nore...@ietf.org> wrote: >> >> Document: draft-ietf-tls-deprecate-obsolete-kex >> Title: Deprecating Obsolete Key Exchange Methods in TLS 1.2 >> Reviewer: Valery Smyslov >> Review result: Ready with Issues >> >> I am the assigned ART directorate reviewer for this document. These comments >> were written primarily for the benefit of the ART area directors. Document >> editors and WG chairs should treat these comments just like any other last >> call >> comments. >> >> The document deprecates the use of RSA and FFDH key exchanges and discourages >> the use of static ECDH cipher suites in TLS 1.2. The document is well written >> and easy to read. I have few minor issues with the document, which I think >> are >> easy to fix. >> >> Issues. >> 1. The draft updates RFC 9325 that is part of BCP 195. I wonder whether this >> draft should also be BCP (and part of BCP 195). > > I would prefer to leave this to the IESG to debate ;) There are times that a > BCP has been updated by a standards track and it has not become part of the > BCP: > - RFC 8407 updated by RFC 8819 > - RFC 8340 updated by RFC 8791 > - RFC 8085 updated by RFC 8899 > - RFC 7595 updated by RFC 8615 > > and the list goes on … > >> 2. It would be nice if there is a summary of changes compared to RFC 9325 >> (which is now the primary source of recommendations for use TLS) somewhere in >> the draft. The draft contains some words regarding that, but they are sparsed >> across the document.
Opps and I missed that there is also this PR, that will land in the next version (thanks Yaron): https://github.com/tlswg/draft-deprecate-obsolete-kex/pull/19 >> 3. The draft never mentiones DTLS, however it updates RFC 6347. I think DTLS >> should be explicitly mentioned as being in scope of this document. >> >> 4. Perhaps some text should be added about potential interoperability >> problems >> (or, as we hope, the lack of such) caused by deprecation of the mentioned key >> exchnage methods. If this could be backed up by some figures from real word, >> it >> would be great. >> >> Nits. >> 1. Throughot document: s/Diffie Hellman/Diffie-Hellman >> >> 2. Does it make sense to update "Historic" RFC 4346, which is obsoleted long >> ago and thus must not be used anyway? > > I can see your point, but it also doesn’t hurt to slam the door shut ;) > > Cheers, > spt > >> 3. Section 2, last para: >> >> These values only apply to TLS versions of 1.2 and >> below. >> >> The text in the preceeding paras contains clarification that TLS 1.0 and TLS >> 1.1 have been already deprecated ("Note that TLS 1.0 and 1.1 are deprecated >> by >> [RFC8996]") and thus are implicitly out of scope. I wonder whether this note >> should also be added here.
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
