I also support adoption of this draft. I share David's observation that the client and server could simultaneously initiate an Extended Key Update, but I had a different mitigation in mind: each side chooses a random value and the higher value wins if there is another ExtendedKeyUpdate already in progress with a lower value. However, I prefer David's design.
nit in Introduction, OLD: including the update keys with a Diffie-Hellman exchange during the lifetime of a session. NEW: including updating keys with a Diffie-Hellman exchange during the lifetime of a session. -d > On Jul 25, 2024, at 3:51 PM, David Benjamin <david...@chromium.org> wrote: > > 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 <mailto:michael.tue...@lurchi.franken.de>> > wrote: >> > On 25. Jul 2024, at 09:39, Sean Turner <s...@sn3rd.com >> > <mailto: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 <mailto:tls@ietf.org> >> > To unsubscribe send an email to tls-le...@ietf.org >> > <mailto:tls-le...@ietf.org> >> >> _______________________________________________ >> TLS mailing list -- tls@ietf.org <mailto:tls@ietf.org> >> To unsubscribe send an email to tls-le...@ietf.org >> <mailto: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
