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

[David Benjamin <[e-mail]>]

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]> wrote:

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