Hi Ilari,
thanks for your feedback. A few remarks below.
Am 05.01.2024 um 16:59 schrieb Ilari Liusvaara:
On Fri, Jan 05, 2024 at 03:11:37PM +0000, Fries, Steffen wrote:
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.
Would that work with groups that are not DH (client and server shares
are not interchangeable)?
My focus was not on PQC algorithms for this work. It was meant as an
extension to be used in the near term.
From Scott's feedback I can see that others seem to have different
priorities.
And would it work with implementations where there is hard constraint
that each key exchange may only be completed once?
No, not in this design. It was not one of the design requirements for me
and, if that's a requirement, then this functionality is probably not
applicable.
Your design proposal below is nice but the number of messages make it
less attractive (even though the use of this mechanism is likely for
devices where performance and bandwidth is less of an issue).
I don't know if it would work for DTLS, but I did come up with design
with four different messages: request, response, ack and crossed.
- Request:
* Has client key share.
* Causes no key change.
* MUST NOT be sent while pending handshake.
* MUST NOT be sent while pending EKU.
* Receiver responds with response if no pending EKU.
* Receiver responds with crossed if pending EKU (will also
happen on the other side).
- Response:
* Has server key share.
* Causes forward key change.
* Reverse keys calculated for install with ack.
* Receiver responds with ack.
- Ack:
* Does not carry key share.
* Causes forward key change (to previously calculated keys).
* EKU completed on send/receive.
- Crossed:
* Has server key share.
* Causes forward key change.
* No reverse key change (done by other crossed EKU).
* EKU completed on send/receive.
The possible flows are (all update keys in both directions):
A) Non-crossed, client initiated:
--- request -->
<-- response ---
--- ack -->
B: Non-crossed, server initiated:
<-- request ---
--- response -->
<-- ack ---
C: Crossed
<-- request -->
<-- crossed -->
Ciao
Hannes
-Ilari
_______________________________________________
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
