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.
>
> 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
