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> 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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
