[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

[Dan Wing <[e-mail]>]

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 <[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> > On 25. Jul 2024, at 09:39, Sean Turner <[e-mail] <mailto:[e-mail]>> 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 -- [e-mail] <mailto:[e-mail]>
>> > To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>> 
>> _______________________________________________
>> TLS mailing list -- [e-mail] <mailto:[e-mail]>
>> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]