Below are some comments on -05.
# Terminology
The discussion of forward secrecy is confusing and arguably wrong. For
instance, consider the abstract:
TLS 1.3 ensures forward secrecy by performing an ephemeral Diffie-
Hellman key exchange during the initial handshake, protecting past
communications even if a party's long-term keys are later
compromised. While the built-in KeyUpdate mechanism allows traffic
keys to be refreshed during a session, it does not introduce new
forward-secret key material. This limitation can pose a security
risk in long-lived sessions, such as those found in industrial IoT or
telecommunications environments.
To address this, this specification defines an extended key update
mechanism that performs a fresh Diffie-Hellman exchange within an
active session, thereby re-establishing forward secrecy beyond the
initial handshake. By forcing attackers to exfiltrate new key
I'm not sure what it means to "reestablish forward secrecy". The TLS
1.3 KeyUpdate mechanism provides forward secrecy, in that a key
compromise at epoch N+1 does not threaten data transmitted
under key N. What this mechanism provides is post-compromise security,
which is to say protection for data protected under key N+1 even
if key N is compromised.
To be clear, I'm not saying that this extension doesn't have value,
merely that that value is not about FS.
# Conflict Resolution and Rejection
The basic structure of this mechanism is that the Initiator
sends a EKURequest and the Responder sends an EKUResponse.
The EKUResponse can be one if:
accepted(0), -- here is my key share
retry(1), -- try again in X seconds
rejected(2), -- I won't update at all
clashed(3), -- I've already initiated my own update
I think we can simplify this somewhat, as detailed below.
## Retry
My initial instinct is we can get rid of "retry" entirely. I see
two main options.
Option 1: Require immediate response
The existing algorithms are relatively cheap and so it's not clear to
me that there is a lot of value in the peer in declining to update,
especially as (unlike KeyUpdate) there can only be one EKURequest
outstanding, so it's not like you can end up with a big pile of
updates to respond to. So, we could just adopt the rule that the
Responder has to send a response more or less immediately.
Option 2: Allow the Responder to unilaterally delay
Rather than having the Responder respond with "retry", the responder
can just unilaterally wait T seconds (where T is whatever it would
have put in the retry response). This simplifies the state machine on
the Initiator and only carries slightly less information, because the
Initiator has no promise that the retry would have worked anyway.
## Clashed
I see what "clashed" is trying to do, but I think there's another
opportunity to simplify: because you are determining which side wins
based on information known both sides, they can each independently
determine which EKURequest will be accepted and which one will be
rejected [0]. So instead of having the winner send a EKUResponse
rejecting the loser, I suggest it just wait for the EKUResponse
from the loser. I.e.,
Client Server
---------------------------------------------------
EKURequest(share=1) -> <- EKURequest(share=2)
[ignores EKURequest]
EKUResponse(share=1) ->
This removes one message and simplifies the state machine because the
losing Initiator can transition directly to sending EKUResponse
without having to have a state waiting for the EKUResponse(clashed)
message.
# Handshake Messages
You're registering 3 new handshake messages out of a space that has
maximum size 256 but is actually quite a bit smaller, as documents
in RFC 7983 (the range that does not require coordination is only
25-63). Is there a reason not to just have a single ExtendedKeyUpdate
mechanism with a type field?
# Label Strings
Do we really need new label strings for the key derivations in S 5? I
haven't done a thorough analysis, but given that you forbid the use of
KeyUpdate in combination with this spec it's not clear to me how you
would get a conflict in terms of the inputs.
-Ekr
[0] If we didn't have to deal with PQ, we actually wouldn't need
any of this machinery and could just exploit the symmetry of DH,
but regrettably we have KEMs.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
