I support adoption of the draft to solve this problem, but I suspect the construction will need some changes. I'm not sure the construction in the draft actually works.
A single extended key update flow in the draft sends NewKeyUpdate in *both* directions. Now, imagine if both client and server initiate an extended key update in parallel. Messages don't get sent instantaneously, so we can't prevent this scenario. We will then have two concurrent instances of this flow: Client-initiated: C->S: ExtendedKeyUpdateRequest1 S->C: ExtendedKeyUpdateResponse1 C->S: NewKeyUpdate1a; update C->S traffic secret S->C: NewKeyUpdate1b; update S->C traffic secret Server-initiated: S->C: ExtendedKeyUpdateRequest2 C->S: ExtendedKeyUpdateResponse2 S->C: NewKeyUpdate2a <-- updates S->C traffic secret C->S: NewKeyUpdate2b <-- updates C->S traffic secret Now, the problem is that NewKeyUpdate1b and NewKeyUpdate2a are the same message, sent in the same direction and may flow in parallel. Same for NewKeyUpdate1a and NewKeyUpdate2b. That means you can get in a situation where *both* flows are waiting for a NewKeyUpdate message and you can't tell which one to progress. If the client and server disagree on the order in which to apply the two secrets, the protocol will break. One could fix this by making the two messages different, but that seems unnecessary. I believe we only need three messages, not four. C->S: ExtendedKeyUpdateRequest S->C: ExtendedKeyUpdateResponse; update the S->C traffic secret C->S: NewKeyUpdate; update the C->S traffic secret I might suggest that NewKeyUpdate be called ExtendedKeyUpdateFinish in this version. This avoids the ambiguity and is simpler. (Not sure what the consequences of either design is on DTLS? I think I'd need to spend time with pen and paper there. Perhaps it is sufficient to just drive the update on ACKs, after apply the fixes described in https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/ ) But, as for adoption, I think solving this problem makes sense, and I think this draft is still a reasonable starting point. David On Thu, Jul 25, 2024 at 1:48 PM Michael Tuexen < michael.tue...@lurchi.franken.de> wrote: > > On 25. Jul 2024, at 09:39, Sean Turner <s...@sn3rd.com> wrote: > > > > At the IETF 120 TLS session there was interest in adopting the Extended > Key Update for TLS 1.3 I-D ( > https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/). > This message starts a two-week call for adoption. If you support adoption > and are willing to review and contribute text, please send a message to the > list. If you do not support adoption of this I-D, please send a message to > the list and indicate why. This call will close on 8 August 2024. > Dear all, > > I do support adoption and I'm willing to work on it, in particular to make > sure that it works on the contexts of DTLS over SCTP, one of its use cases. > > Best regards > Michael > > > > Thanks, > > Sean > > _______________________________________________ > > TLS mailing list -- tls@ietf.org > > To unsubscribe send an email to tls-le...@ietf.org > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
