Hi Scott,
thanks for your feedback. Introducing PQC algorithms in the design for this proposal has not been discussed in TSVWG design team and has therefore not been a requirement for me. (Maybe my co-authors see this differently.) I will bring this topic up in the next design team call. In any case, it is good to hear your preferences. Ciao Hannes Am 05.01.2024 um 20:52 schrieb Scott Fluhrer (sfluhrer):
Here’s an issue I see with postquantum exchanges; Kyber (and most other postquantum key exchanges) would have an issue with the current format. There are distinct ‘initiate key shares’ and ‘response key shares’, and they’re not interchangeable; a ‘response key share’ must be generated for a specific ‘initiate key share’. Now, it would be possible to extend ExtendedKeyUpdate to include a flag stating whether this is a request for new keys, or a response (distinguishing the two cases); that would be a relatively small change. However, what happens if both sides happen to issue ExtendedKeyUpdate at the same time? With DH, it’s not an issue; they could ignore the flag, and they would both accept the other’s ExtendedKeyUpdate as a response to their own, and both update the keys in the same way. However, with Kyber, if we issue an ‘initiate key share’ and get an ‘initiate key share’ in response, we can’t generate keys. One possibility would be if there is a tie-breaker between the two sides (such as ‘who had the lexically larger key share)’; the loser of that tie-breaker would discard his original ExtendedKeyUpdate, and reissue another one (which is a response to the other side’s)? I believe this idea would extend to DTLS as well as TLS. A bit kludgy (and definitely adding complexity); however I also believe that it would be short-sighted to ignore postquantum crypto at this point. *From:*TLS <tls-boun...@ietf.org> *On Behalf Of *Tschofenig, Hannes *Sent:* Thursday, January 4, 2024 6:42 AM *To:* TLS List <tls@ietf.org> *Subject:* [TLS] Key Update for TLS/DTLS 1.3 Hi all, we have just submitted a draft that extends the key update functionality of TLS/DTLS 1.3. We call it the “extended key update” because it performs an ephemeral Diffie-Hellman as part of the key update. The need for this functionality surfaced in discussions in a design team of the TSVWG. The need for it has, however, already been discussed years ago on the TLS mailing list in the context of long-lived TLS connections in industrial IoT environments. Unlike the TLS 1.3 Key Update message, which is a one-shot message, the extended Key Update message requires a full roundtrip. Here is the link to the draft: https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/ I am curious what you think. Ciao Hannes _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
