On Wed, Sep 3, 2025 at 11:37 PM Mohamed Boucadair via Datatracker < [email protected]> wrote:
> Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-hybrid-design-15: 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: > ---------------------------------------------------------------------- > > Hi Douglas, Scott, and Shay, > > Thank you for the effort put into this well-written document. It is an > interesting read. > > Thanks also to Tim Chown for the OPSDIR review and the authors for > engaging. > > Please find below some comments: > > # Why is this Informational? > > The justification in the writeup seems clear to me. I do think that it > would be > useful to mirror in the abstract or the Introduction the main message > grabbed > from the writeup: > > “It does not modify TLS directly, but rather using existing mechanisms and > code > point registries. It does not define any specific hybrid key exchanges.” > > This statement may be revisited based on the outcome of the next item. > > # Relaxing a MUST in the base TLS spec? > > CURRENT: > [TLS13] requires that ``The key_exchange values for each > KeyShareEntry MUST be generated independently.'' In the context of > this document, since the same algorithm may appear in multiple named > groups, this document relaxes the above requirement to allow the same > key_exchange value for the same algorithm to be reused in multiple > KeyShareEntry records sent in within the same ClientHello. > > Isn’t this modifying aspects of the base TLS? How to reconcile this with > the > claim in the previous point? > >From a technical perspective I'd like to revisit this point. My memory is that the plausible KEMs actually have fast key generation, as does EC. Why not just keep the requirement as-is? -Ekr > # IANA considerations > > Unless I missed something the document provides guidance for future > assignments. Shouldn’t a note be added to the TLS registry to track this > guidance and/or add this document as a reference to the registry? > > As I’m there, > > CURRENT: > For these entries in > the TLS Supported Groups registry, the "Recommended" column SHOULD be > "N" and the "DTLS-OK" column SHOULD be "Y". > > I guess this should be the value used in the initial registration. The > recommended value may in theory evolve in the future (far future, maybe). > If > so, can we make that explicit in the document? > > # Minor/nits > > ## Section 1.2 > > OLD: for example, FIPS compliance. > NEW: for example, US National Institute of Standards and Technology (NIST) > FIPS > compliance. > > ## Section 1.5 > > OLD: as long as as > NEW: as long as > > ## Section 2 > > CURRENT: > The main security property for KEMs is indistinguishability under > adaptive chosen ciphertext attack (IND-CCA2), .. > ^^^^^^^^ > > A weaker security notion is indistinguishability under chosen > plaintext attack (IND-CPA), > ^^^^^^^^ > > Can we cite references for these two? > > ## Section 3.2 > > CURRENT: > Recall that in TLS 1.3 a KEM public key or KEM ciphertext is > represented as a KeyShareEntry: > > Can we have an explicit reference to rfc8446#section-4.2.8 for readers > convenience? > > Idem for: > > CURRENT: > [TLS13] requires that ``The key_exchange values for each > > Cheers, > Med > > > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
