Thank you for the feedback. I've addressed the minor/nits in https://github.com/dstebila/draft-ietf-tls-hybrid-design/commit/fde2d4ea3c5e59ee9c27de7e7408db1dbe1bccf3.
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. # 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. 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. Douglas
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
