I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-tls-hybrid-design-13
Reviewer: Paul Kyzivat
Review Date: 2025-06-27
IETF LC End Date: 2025-07-01
IESG Telechat date: ?
Summary:
This draft is on the right track but has open issues, described in the
review.
ISSUES: 2
NITS: 3
1) ISSUE: Intended document status
The intended status of this document is Informational. But there is
extensive use of RFC2119 keywords in ways that certainly sound normative
on implementations of hybrid key exchange. And there are specific
instructions for IANA to follow.
I suggest that the intended status of this document should be Standards
Track.
2) ISSUE: Another possible performance issue
(Note: This reviewer has minimal understanding of the mechanics of
encryption algorithms. Read the following with that in mind.)
If I understand correctly, section 3.3 says that the concatenated shared
secret becomes the symmetric key for the resulting session.
If so, won't its increased length increase the cost of data exchange in
the session? I don't see a discussion of that.
3) NIT: An ambiguity
The Abstract says:
"even if all but one of the component algorithms is broken"
This is ambiguous. It could mean either:
* "even if all but one of the component algorithms is defective", or
" "even if a way has been found to defeat the encryption for all
but one of the algorithms"
I presume you intend the latter. Please be more precise, at least in the
abstract. I understand that "broken" is a term of art in the context of
encryption algorithms, so it may be fine to use it without qualification
in the body of the document. But the abstract has a more diverse set of
readers.
4) NIT: Editorial
In the Abstract, the following statement:
"Discussion of this work is encouraged to happen on the TLS IETF mailing
list tls@ietf.org or on the GitHub repository which contains the draft:
https://github.com/dstebila/draft-ietf-tls-hybrid-design.";
is an editorial comment that should be removed in the RFC.
There should be a note to the editor to remove it.
5) NIT: Invalid 2119 language
The IdNits utility reports:
"The document seems to lack the recommended RFC 2119 boilerplate, even
if it appears to use RFC 2119 keywords -- however, there's a paragraph
with a matching beginning. Boilerplate error?
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires)."
I didn't investigate exactly what is wrong. Please fix it.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
