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? # 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 -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
