On May 22, 2025, at 3:34 PM, Sean Turner <sean@xxxxxxxxx> 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 <noreply@xxxxxxxx> 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 8615and 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):
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,spt3. 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.
|
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
