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
> <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 …
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.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
