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)?
And would it work with implementations where there is hard constraint
that each key exchange may only be completed once?
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 -->
-Ilari
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
