Éric Vyncke has entered the following ballot position for draft-ietf-tls-hybrid-design-14: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-tls-hybrid-design-14 CC @evyncke Thank you for the work put into this document. Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education). Special thanks to Joe Salowey for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## 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... ;-) Who is the "we" in `we do not limit`? The authors, the WG, the IETF ? Please avoid using ambiguous "we" in an IETF document. 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. s/that is not Diffie-Hellman-based nor a group/hat is *neither* Diffie-Hellman-based nor a group/ ? ### Section 1.4 s/session authentication cannot be retroactively broken/breaking retroactively session authentication is pointless/ ? ### 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". ### 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. Please add another informational reference to explain what "IND-CCA2" is (and later in the text "IND-CPA"). 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 ? ### Section 3.3 As non-US "NIST" may appear, let's s/NIST/US NIST/ (and possibly expand NIST). ### 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" ? ### 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. 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" ?). Suggest to add guidance to IANA to implement `These assignments should be made in a range that is distinct` ## NITS (non-blocking / cosmetic) ### E.g. AFAIK, "e.g." should be surrounded by ",". ### 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 ;-) _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
