Hi David, In addition to what Hannes stated, the alternative in Appendix B was the result of further thoughts on potential alternatives keeping the single shot approach of the keyUpdate in TLS 1.3.
The intension was to have an ephemeral-static DH exchange, which uses the previously used DH key of the receiver R and an ephemeral DH parameter for the sender S in the ExtendedKeyUpdate. That way, both sides can immediate generate a new session key without any interruption. The receiver R may then directly react with a ExtendedKeyUpdate utilizing the updated DH key of S and an own ephemeral DH key for R. That way both sides have stepwise contributed an ephemeral DH part. As the ExtendedKeyUpdate messages are independent, application data may still be exchanged in between, without introducing waiting time. While keeping the single shot feature, this approach would have the disadvantage, that the last received DH key needs to be stored in cases it is needed for an ephemeral-static exchange. But this may be easier to handle. Best regards Steffen From: TLS <tls-boun...@ietf.org> On Behalf Of Hannes Tschofenig Sent: Friday, January 5, 2024 3:53 PM To: David Benjamin <david...@chromium.org>; Tschofenig, Hannes <hannes.tschofenig=40siemens....@dmarc.ietf.org> Cc: TLS List <tls@ietf.org> Subject: Re: [TLS] Key Update for TLS/DTLS 1.3 Hi David, thanks for sharing your thoughts. Here is the approach I had in mind: the application code needs to trigger the TLS/DTLS stack to start the extended key update. For the TLS 1.3 code I wrote, that's the approach I took for the regular TLS 1.3 key update as well. In the use cases I have in mind, the application knows whether it has application data to send and therefore what a good timing for such an extended key update would be. You are correct that there is a short time window when the sender of the extended key update has to wait till it receives the response from the peer party to also update its sending keys. I have not considered running the extended key update in parallel to the application data exchange and the use of a three message exchange. It may be possible that this approach is not possible in environments where there is a continuous stream of packets or where potential delays in sending data are unacceptable. I suspect you have such an environment (?). When I also take the comments from Thom into account, who didn't like the change to the state machine with the full-round-trip approach, I am wondering whether the alternative of using a semi-static DH, which we considered in Appendix B, may ultimately be better. Ciao Hannes Am 05.01.2024 um 01:40 schrieb David Benjamin: 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<mailto: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<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
