[TLS] Re: Artart ietf last call review of draft-ietf-tls-deprecate-obsolete-kex-05

[Sean Turner <[e-mail]>]

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 <[e-mail]> 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.