We have pushed version 14 to address some of these nits: > > 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.
I replaced this section with the bcp14 boilerplate and the nits tool seems much happier <https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tls-hybrid-design-14.txt> > 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. RFC 2119 does not mention document track. There are a number of cases where protocol documents are information-only <https://datatracker.ietf.org/doc/rfc8773/>, not internet standards, and have normative requirements. On Fri, Jul 18, 2025 at 12:29 AM Douglas Stebila <[email protected]> wrote: > 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 [email protected] 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 <[email protected]> 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 [email protected] 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. > >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
