Hi Thom
thanks for the quick review.
Directionality of the extended key updates: I should be more clear in
the examples and in the write-up that these key updates can be initiated
by both parties.
Description about when the keys can be deleted: I will re-review the
text again to improve the wording.
Alternative designs: At the start I have been quite excited about the
idea of preserving the one-shot semantics of the key update.
Unfortunately, it comes with a price, as you also point out. Building
the design on top of draft-ietf-tls-semistatic-dh or AuthKEM may have
been possible as well but introduces dependencies that not everyone likes.
Ciao
Hannes
Am 04.01.2024 um 15:12 schrieb Thom Wiggers:
Hi Hannes,
Skimming the document, I had the following questions:
- Can only clients request extended key updates (EKUs)? I think the
text does not attempt to impose this as a restriction, but all the
examples are client-initiating.
- If it is limited to client-initiated EKUs, the client shouldn't need
to indicate it supports this extension?
- Section 5 specifies that the N-1 keys SHOULD be deleted once
computed, but in many other sections (e.g. the tail of section 4) keys
are specified (MUST) to stay around for a bit longer. This seems
contradictory, and I think it would be less confusing if handling of
key material is more explicitly treated in the document.
Personally, I’m not super stoked about having extensions that bolt on
a new state machine, but it seems unavoidable for your problem
description (if we’re excluding application-layer fixes).
Your "alternative designs considered” section might have been more
viable if this was built on top of draft-ietf-tls-semistatic-dh or
AuthKEM, as we’d have long-term static key exchange keys (but it does
have other complications, such not allowing server-initiated EKUs if
there was no client auth). Otherwise I think that you’re right to not
require servers to store their ephemeral keys for the session lifetime
if the client sends an extension, while it may never even send the EKU
request.
Cheers,
Thom
Op 4 jan 2024, om 12:42 heeft Tschofenig, Hannes
<hannes.tschofenig=40siemens....@dmarc.ietf.org> het volgende geschreven:
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
