>> # 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?
This seems like a sufficiently significant change (on text that has been present in the draft since 2020) that I’ll need guidance from the working group / chairs on how to proceed. Do any implementations currently do that? My quick check of Chrome using Wireshark seems to show different EC points used in the two transmitted keyshares (MLKEM768X25519 versus X25519), but that’s not an exhaustive check. Douglas
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
