Thanks for the feedback. Response to comments inline below. Updates pushed to
https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/49. I’ll post a
new ID once I get an approval on the changes from one of the TLS chairs.
Douglas
On Sep 2, 2025, at 2:02 AM, Éric Vyncke via Datatracker <nore...@ietf.org>
wrote:
>
> ## COMMENTS (non-blocking)
>
> ### Section 1.2
>
> s/Algorithms which are widely deployed today, but *which* may be deprecated in
> the future/Algorithms *that* are widely deployed today, but may be deprecated
> in the future/ ?
> Same for 'next-gen' ;-) I sincerely hope that TLSng will be faster to deploy
> than IPng, aka IPv6... ;-)
Done
> Who is the "we" in `we do not limit`? The authors, the WG, the IETF ? Please
> avoid using ambiguous "we" in an IETF document.
We have replaced these.
> After introducing "component" and "composite", the text states `It is intended
> that the composite algorithms` while the preceeding text seems to prefer not
> using "composite". Nothing dramatic but puzzling.
Done.
> s/that is not Diffie-Hellman-based nor a group/hat is *neither*
> Diffie-Hellman-based nor a group/ ?
Done.
> ### Section 1.4
>
> s/session authentication cannot be retroactively broken/breaking retroactively
> session authentication is pointless/ ?
Left as is; authenticating a session is an action taken at a point in time, and
indeed it cannot be changed retroactively. One could of course decrypt or forge
or do something about messages that were used during that action, but that’s
not the same as breaking the event.
> ### Section 1.5
>
> When reading the part about the sheer size of the key exchange, I wonder
> whether some text (perhaps in another doc) should be authored for 'contrained'
> networks (being in ressource or network bandwidth). Strongly suggest adding a
> sentence around "Using hybrid in constrained systems may not be suitable" or
> something similar to state that the TLS WG have not ignored the "IoT world".
The following sentence was recently added:
The tolerance for lower performance / increased latency due to use of
hybrid key exchange will depend on the context and use case of the systems and
the network involved.
I think this conveys some of those concerns, without making blanket advice.
> ### Section 2
>
> While I trust the I-D authors to know more than me, I am puzzled by reading
> "secret key" rather than "private key", which seems more popular.
The terms are used interchangeably within cryptography.
> Please add another informational reference to explain what "IND-CCA2" is (and
> later in the text "IND-CPA").
Done.
> The last sentence contains 2 "MUST", but aren't these "MUST" applicable to
> *any* key TLS key exchange ? I.e., not only to "hybrid" ones ?
Yes; given the importance of not reusing randomness, it seems worthwhile to
re-emphasize the point.
> ### Section 3.3
>
> As non-US "NIST" may appear, let's s/NIST/US NIST/ (and possibly expand NIST).
I have expanded the acronym on first use.
> ### Section 4
>
> Should there be an informal reference to `Classic McEliece`?
>
> Should the "can" in `Clients can retry if a failure is encountered` be
> replaced
> by "MAY" or even a "SHOULD" ?
Changed to MAY.
> ### Section 5
>
> Please add an informal reference to the IANA registry URI
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8.
Done
> I was not expected an informational RFC to state such a strong binding
> statement `For these entries in the TLS Supported Groups registry, the
> "Recommended" column should be "N" and the "DTLS-OK" column should be "Y".`
> (at
> least this is a "should"... should this has been a "SHOULD" ?).
Changed to SHOULD.
> Suggest to add guidance to IANA to implement `These assignments should be made
> in a range that is distinct`
I don’t understand this comment. The document already contains the sentence
"These assignments should be made in a range that is distinct from the Finite
Field Groups range."
>
> ## NITS (non-blocking / cosmetic)
>
> ### E.g.
>
> AFAIK, "e.g." should be surrounded by ",".
Done
> ### Use of SVG graphics
>
> To make a much nicer HTML rendering, suggest using the aasvg too to generate
> SVG graphics. It is worth a try especially if the I-D uses the Kramdown file
> format ;-)
The relevant figure (Key schedule for hybrid key exchange) is an adaptation of
a corresponding figure in the TLS 1.3 spec (RFC 8446), and given that this
document will be read in concert with the 8446, I would like to keep the clear
connection to the existing figure.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
