Hi,
IANA’s understanding is that because the IANA Considerations includes guidance concerning future assignments, we have to list this document as an additional reference for the registry itself. Thanks, Amanda From: "[email protected]" <[email protected]> Date: Monday, September 8, 2025 at 3:02 AM To: Douglas Stebila <[email protected]> Cc: The IESG <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Subject: [Ext] RE: Mohamed Boucadair's No Objection on draft-ietf-tls-hybrid-design-15: (with COMMENT) Hi Douglas, Thanks for the follow-up. Please see inline. Cheers, Med De : Douglas Stebila <[email protected]> Envoyé : dimanche 7 septembre 2025 18:14 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Objet : Re: Mohamed Boucadair's No Objection on draft-ietf-tls-hybrid-design-15: (with COMMENT) Thank you for the feedback. I've addressed the minor/nits in https://github.com/dstebila/draft-ietf-tls-hybrid-design/commit/fde2d4ea3c5e59ee9c27de7e7408db1dbe1bccf3 [github.com]. [Med] Thanks. Regarding the comments, see inline below: # 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? You are correct that this relaxes as MUST in the base TLS spec, and as such a statement saying "It does not modify TLS directly" would not be fully accurate. If you have some other wording you would suggest to add to the introduction, please feel free to suggest it. [Med] Thanks for confirming. Maybe consider something such as : « Except relaxing a MUST on key_exchange values, this document does not require any modification to the base TLS specification.“ or similar. Given that implication on base TLS spec, I’m afraid that the intended publication status should be reconsidered. # 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? I do now know what text IANA would want to see here; my understanding from IANA's review is that they have not requested any further changes. [Med] Beyond what need to be recorded in an IANA registry, the main point is that this section sets guidance for future assignments and we need to make sure that guidance is followed. 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? For what reasons do you expect this recommendation may evolve? I am not sure what text to write other than "The recommended value may change in the future", which I think is too vague. [Med] I was actually suggesting this change: OLD: the "Recommended" column SHOULD be … NEW: the "Recommended" column SHOULD in the initial registration be … Douglas ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
