IETF Last Call Review of draft-ietf-tls-hybrid-design-13
review-ietf-tls-hybrid-design-13-genart-lc-kyzivat-2025-06-27-00

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.