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

[Valery Smyslov <[e-mail]>]

Hi Sean,

please see inline.

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

No problem, I just wanted to draw attention to this. 

> > 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 ;)

Again, no problem, I only asked (I'm not sure historic documents are formally allowed to be updated) :-)

Regards,
Valery.

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