Skimming the draft, I am not following the timing of this process. Suppose the client initiates an extended key update. It cannot update the keys yet, because it does not know the server's response. It needs to keep reading from the server. In doing so, it will hopefully see a responding ExtendedKeyUpdate, but it may see something else that forces it to send data, such as an application protocol message or an update_requested KeyUpdate. (Or perhaps an update_requested ExtendedKeyUpdate!)
Are you envisioning that the client is unable to send anything until it receives the server's response, or that this exchange flows in parallel with the rest of the connection? If the client is unable to send anything, this seems like it would cause problems. Certainly it would not be something the TLS library can do automatically, because it can only run at a quiet point in the application protocol. A priori, you may receive an unbounded amount of application data while waiting for ExtendedKeyUpdate. You need to do *something* with that data, but all options result in either an unbounded buffer or a deadlock somewhere. If the exchange flows in parallel, how does the server know where, in the client stream, did the client switch keys? I think you'd need a third message to mark this point.Though we then need to reason through what happens if that third message doesn't come in for a long while, because the server can't release state from that key update until then. To that end, what happens if someone sends a storm of ExtendedKeyUpdate messages with update_requested in a row? Over TCP, we have to worry about a DoS issue caused by asymmetric rates on the two sides. (If I send you a storm of update_requested but refuse to read from the socket, at some point backpressure will stop you from writing responses. At that point, you need to know to stop reading or you'll buffer up unbounded data.) For plain KeyUpdate, we said the requests can be coalesced, but ExtendedKeyUpdate messages contain different key shares. I suspect you need to say that you cannot send a new update_requested until after you've sent the third message for the previous one. Relatedly, this seems tricky: > If implementations independently send their own ExtendedKeyUpdate messages, and they cross in flight, the result is that each side increments keys by two generations. Since ExtendedKeyUpdate incorporates new key material into the new secret, you will get a different result depending on which exchange is processed first. But the two sides may see each exchange resolving in a different order when crossed like this. (It *might* work with a three-message design? Then there's an in-band signal for when the keys are applied on each side. Though it means this cross case can actually resolve in different orders for the two streams, which is kind of interesting.) On Thu, Jan 4, 2024 at 6:42 AM Tschofenig, Hannes <hannes.tschofenig= 40siemens....@dmarc.ietf.org> 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. > > > > The need for this functionality surfaced in discussions in a design team > of the TSVWG. The need for it has, however, already been discussed years > ago on the TLS mailing list in the context of long-lived TLS connections in > industrial IoT environments. > > Unlike the TLS 1.3 Key Update message, which is a one-shot message, the > extended Key Update message requires a full roundtrip. > > > > Here is the link to the draft: > > https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/ > > > > I am curious what you think. > > > > Ciao > Hannes > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
