Hi Ilari,
thanks again for the super quick feedback. Remarks below:
Am 04.01.2024 um 14:53 schrieb Ilari Liusvaara:
On Thu, Jan 04, 2024 at 11:42:13AM +0000, Tschofenig, Hannes 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/
Some quick comments:
- The supported_groups in EE is optional. The group used in initial
handshake is always considered supported, right?
When exchanging key shares, the use of supported_groups is mandatory (at
least that's what I remember).
It would, however, be useful to point out that this needed. As such, the
extended key update is not useful for cases where you only use PSK-based
authentication without a (EC)DHE key exchange.
- I can't quite parse what is going on in figure 3.
Figure 3 is supposed to show you how the extended key update works in
DTLS 1.3 with epoch values indicating when the keys in the different
directions change.
Let me think about how to better get the story across.
- The endpoint sending EKU with update_requested is the initiator for
groups that have asymmetric roles, right?
The client sends an EKU to the server in an attempt to
update the traffic key for traffic sent from itself to the server.
If it also wants to trigger the server to update the traffic keys in the
reverse direction, namely from the server to the client, it needs to set the
update_requested flag. Then, the server will have to trigger a separate
exchange.
Did I understood you correctly?
- Crossed extended key update with DTLS sounds complicated enough that
there should be an argument it works even with various message loss
or reordering patterns.
Happy to add more text.
- TLS 1.3 limits labels in key schedule to 12 bytes (so that all the
data fits into SHA256 block), but the label used here appears to
be 13 bytes.
Good catch. Will change that.
Ciao
Hannes
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
