[TLS] DTLS 1.3 rekeying and the use of epoch values

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 08 July 2016 14:21 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5027112B00F for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 07:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.027
X-Spam-Status: No, score=-4.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VOwGONJSmWIc for <tls@ietfa.amsl.com>; Fri, 8 Jul 2016 07:21:35 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7CE12D098 for <tls@ietf.org>; Fri, 8 Jul 2016 07:21:34 -0700 (PDT)
Received: from [] ([]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0M8edX-1bXoQ309yd-00wBZ6 for <tls@ietf.org>; Fri, 08 Jul 2016 16:21:32 +0200
To: "<tls@ietf.org>" <tls@ietf.org>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
X-Enigmail-Draft-Status: N1110
Message-ID: <577FB6EA.4070101@gmx.net>
Date: Fri, 08 Jul 2016 16:21:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="V5NWPdHEftSWTVP5V8J3xPOhIB5BLWuqF"
X-Provags-ID: V03:K0:0nq/hjlnB5MfKFSWXkulAMygtPviXtqM1kUunVzjLxtnQQtCPve 5FKCW95eugrP1VEo0vQOqJH1K/jkcHbYm8/8v+2eQ9rsNBqyOvGlYOGlC/F1ov0yhCdU13y UVWVKd1ZGN3ZHgV7OGcqltIgD8zLf5aEmU9tv49v5Zn3OQkvB54Pt2g+b7EKFf31SqhuB5w 7ckRc0C4Rf+vAk+cAQasQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:nQiiTz7feyg=:cip8kfJDJgX9GPWuZhLnDh JkqKga7hPqebZH0UHJWHJkayh4Muf3uOdcwxaWmX3VWrfsiMu02BWGLExAf2Pta3tdu6knGeq lmp2HQXmIsU+do2uvYR2dVy4ptCLwPv91CoAQs9rVkyBUhUw//11qUanE8OwDxd48CNaqzoxE DqcOIYfflaS9ZHJYi0jtFBh9NN4/THK2vw7sBJ1bo7kHM2S4h+IFp1uxbFMhNWsitJPPSHQxp fEw+KaiHu11dLsme4pujKPI2sRCOT/1/Uu86mukjfVI9IBRHmDg9BmG6iLeo7/P7CkATk0H5K HWEJo/DCNJvKlQUqyuN7SVdQoJbmH2bMznk2lqu6qgTtMz6K/AlpDjd08fNmpzcsNEiUYTqEI bDNLcAeSnGgO9rQHMAFCtYKliYTAtJAI5ZLjFeVZvu6+jIMwR7yUVcbdnDlJp7FiFK4jstpXC lBtCZNQtseMqxXCG4M9svNR9m3r4V94gUJRApvpL30GcJ3nyEps6PfNKaeE38UZBcTXmJOTwr hEr4w4dJyZ1on5Gd3g6Ci9VNdzvocQZHy4FE60lUNWS3N3urFyjJ12FCgeBwleKaaIRXMFuY1 QVsbA4qGcLBfqpyc7OG6zIj8cuutiS1HSxFLaBlv/kf1rUQ/ywRHTt5+4PibEjpAaCSO8BYZu UHiqUGIxejCh1kSjTlbBoMEXnsysX1FPdo1jQwLfXRUqd3furO7jLa9nvA80My7coJ475Te04 l6HF/d3pnBc3l1T21xv8/fkoXq9D5qfzn0tVzEqTucpa0FBZLfpMoloB298=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jN7-Whl68ICamy6RpX_pqPNTUwU>
Subject: [TLS] DTLS 1.3 rekeying and the use of epoch values
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Jul 2016 14:21:37 -0000

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

   -  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

   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.