On Thu, Jan 04, 2024 at 11:42:13AM +0000, Tschofenig, Hannes wrote: > 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. > > [...] > > > Here is the link to the draft: > > > [1]https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/
A few thoughts from a quick read (to supplement the good comments already received): - I'm not sure that the current condition "can be sent by either peer after it has sent a Finished message" will work quite right for the DTLS case; I think that you'd need to also know that your Finished has been processed before sending EKU, in order to ensure that the peer will accept it. - I'd probably drop the "perfect" from "perfect forward secrecy" -- you already quote the bit from RFC 9325 that uses just "forward secrecy" as the primary term and I don't see much reason to diverge from that. - The discussion of truncation attacks near the end of §4.1 doesn't seem quite right w.r.t. DTLS, in that DTLS is always going to be susceptible to truncation attacks (but I do think that the requirement you propose should still be enforced). - The prose discussion of the key schedule should probably get tweaked a bit; it makes it sound as if application_traffic_secret_N is not used at all (it's currently put in as the "messages" parameter to Derive-Secret(), if I'm reading correctly) and that the dh-secret is used directly in HKDF-Expand-Label() (which would be misuse since it's not uniformly random and needs an HKDF-Extract first, as is shown in the actual figure). - I'm not sure about using application_traffic_secret_N as the "messages" input to Derive-Secret() -- that would seem to imply that we hash it as a transcript hash??? Why not use it as HKDF-Extract input alongside dh-secret? - I'm not sure I'd put something about hybrid key exchange in at this point, and IIRC the concatenation secret combiner is not known to be the best choice of secret combiner. Thanks, Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
