My apologies for the delay. Responses inline below. > 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. I will need guidance from the TLS working group chairs on how to proceed with the intended status. > 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. The concatenated shared secret does not directly become the symmetric key for the resulting session. Instead, the concatenated shared secret is input into a key derivation function within the TLS key schedule, which effectively hashes the concatenated shared secret down to the same length as current symmetric key lengths. While it is true that it may take slightly longer to hash with a concatenated shared secret instead of a single shared secret, it is a one-time cost and costs at most one more application of the hash function function compression function, which is quite small. > 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. Fixed in https://github.com/dstebila/draft-ietf-tls-hybrid-design/commit/68cc6d246c7599ca4f062f05b6c8b7a6178fa385. I'll post a revised Internet-Draft once I get a conclusion on issue 1 above. > 4) NIT: Editorial > > In the Abstract, the following statement: > > "Discussion of this work is encouraged to happen on the TLS IETF mailing list tls@xxxxxxxx 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. Fixed. > 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. The document uses the language from RFC 8174. Is that not acceptable? Douglas > On Jun 27, 2025, at 6:48 PM, Paul Kyzivat <pkyzivat@xxxxxxxxxxxx> wrote: > > 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@xxxxxxxx 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
