I have reviewed the I-D and I agree with others that it is a simple
solution and that will benefit implementation. I have only a few
minor comments on the text.
- Section 1.2, definition of "Hybrid" should clarify that the key
exchange algorithms are to be performed (negotiated and transmitted,
as it says in the Introduction) within the TLS 1.3 handshake.
Otherwise, hybrid could cover out-of-band mechanisms that contribute
key material (draft-ietf-tls-external-psk-importer).
- Section 1.2, paragraph beginning with "The primary motivation...":
It says that it is possible alternative public key constructions "will
be required... for example because of a cryptanalytic breakthrough".
I suggest changing "required" to "desired to mitigate risks".
- Section 1.3, motivation: There are many cases considered under
motivation, without clearly stating the combination of mechanisms that
might achieve the goals. If this is meant to be left to the reader,
then I suggest adding a sentence to the final paragraph that says:
"Users should consider the confidence they have in each hybrid
component to assess that the hybrid system meets the desired
motivation."
- Section 1.3: s/due the threat of/due to the threat of
- Section 3.1: The term "codepoint" was not used in RFC 8446 (though
it does use "Code Points" in the comments of the IANA registry
tables). In this instance in the text, I suggest replacing it with
"value" or "identifier" to align.
- Section 1.2 defines hybrid in this context to mean "two (or more)
key exchange algorithms". However elsewhere, such as Section 3.1
("ordered pair of two algorithms") and Section 3.3 ("the two shared
secrets are concatenated"), the descriptions assume that only two
algorithms are used. I see no technical reason to limit to two
algorithms.
Best regards,
Jonathan
Canadian Centre for Cyber Security
On Wed, Apr 27, 2022 at 11:28 AM Christopher Wood <c...@heapingbits.net> wrote:
>
> This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
> located here:
>
> https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>
> We do not intend to allocate any code points at this time and will park the
> document after the call is complete. Once CFRG produces suitable algorithms
> for consideration, we will then add them to the NamedGroup registry through
> the normal process [1] and move the document forward.
>
> Please review the draft and send your comments to the list. This WGLC will
> conclude on May 13.
>
> Best,
> Chris, for the chairs
>
> [1]
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
