FWIW I actually preferred the clarity improvements and explicit scope of -06 in the motivation.
What does "targeting simplicity" mean in the context of TLS? The simplest thing is to omit TLS altogether. I believe the motivation should highlight and somewhat elaborate the tradeoff between a "lines of code" number (resp. maintainability resp. number of concepts to understand) and the omission of another potential security measure like a ECDHE. If "simplicity" really is meant as any of the above, then the draft should probably restrict that aspect to implementations where ECDHE isn't also implemented to give the reader a clear picture of the benefits. "Constrained environments" I think was a good term for such settings. I can contribute some text for consideration if the authors believe this to be helpful. I also preferred the explicit mentioning of middleboxes, since this was a consideration which came up on this list. Is there a reason why this was removed? Regarding the regulatory frameworks, TLS's hybrid key establishment _is_ a standalone PQ key establishment. I still have yet to see a framework which allows using ML-KEM and hash arbitrary "Extensions", "Client Nonces" and "Legacy Session IDs" into the key, yet makes an exception for the output of a random algorithm called "ECDHE". Honestly, I would be very worried if I ever saw that anywhere... -- TBB
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
