Hi all, based on the feedback from Ilari this week I have drafted initial text that talks about rekeying and the use of the epoch value.
----
8.8. Epoch Values and Rekeying
A recipient of a DTLS message needs to select the correct keying
material in order to process an incoming message. With the
possibility of message loss and re-order an identifier is needed to
determine which cipher state has been used to protect the record
payload. The epoch value fulfills this role in DTLS. In addition to
the key derivation steps described in Section 9 triggered by the
states during the handshake a sender may want to rekey at any time
during the lifetime of the connection and has to have a way to
indicate that it is updating its sending cryptographic keys.
The following epoch values are reserved and correspond to phases in
the handshake and allow identification of the correct cipher state:
- epoch value (0) for use with unencrypted messages, namely
ClientHello, ServerHello, and HelloRetryRequest.
- epoch value (1) for the Finished message protected using the 0-RTT
handshake key.
- epoch value (2) for 0-RTT 'Application Data' protected using keys
derived from the
early_traffic_secret.
- epoch value (3) for messages protected using keys derived from the
handshake_traffic_secret, namely the EncryptedExtensions to the
Finished message sent by the client).
- epoch value (4) for application data payloads protected using keys
derived from the initial traffic_secret_0.
- epoch value (5 to 2^16-1) for application data payloads protected
using keys from the traffic_secret_N (N>0).
Using these reserved epoch values a receiver knows what cipher state
has been used to encrypt and integrity protect a message.
Implementations that receive a payload with an epoch value for which
no corresponding cipher state can be determined MUST generate a fatal
"unexpected_message" alert. For example, client incorrectly uses
epoch value 5 when sending application data in a 0-RTT exchange with
the first message. A server will not be able to compute the
appropriate keys and will therefore have to respond with a fatal
alert.
Increasing the epoch value by a sender (starting with value 5
upwards) corresponds semantically to rekeying using the KeyUpdate
message in TLS 1.3. Instead of utilizing an dedicated message in
DTLS 1.3 the sender uses an increase in the epoch value to signal
rekeying. Hence, a sender that decides to increment the epoch value
(with value starting at 5) MUST send all its traffic using the next
generation of keys, computed as described in Section 9.2. Upon
receiving a payload with such a new epoch value, the receiver MUST
update their receiving keys and if they have not already updated
their sending state up to or past the then current receiving
generation MUST send messages with the new epoch value prior to
sending any other messages. For epoch values lower than 5 the key
schedule described in Section 9.1 is applicable.
Note that epoch values do not wrap. If a TLS implementation would
need to wrap the epoch value, it MUST terminate the connection.
----
Ciao
Hannes
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
