Re: [TLS] Why is resumption_context hashed?

Hugo Krawczyk <> Sun, 17 July 2016 05:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6074812B040 for <>; Sat, 16 Jul 2016 22:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3oY_QX96WAam for <>; Sat, 16 Jul 2016 22:44:56 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 36AAB12B00C for <>; Sat, 16 Jul 2016 22:44:56 -0700 (PDT)
Received: by with SMTP id y188so2925498ywf.0 for <>; Sat, 16 Jul 2016 22:44:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=P7VyUIyVjfG38SPrBq3P+p0ps19raOJyGquUrJEwq7o=; b=ikB2yStDRUWbGtQVoDuniyEoCYpQ//XpPSqlSmQDx0ovr7HqSkfHbzLVP81CJSF829 sLt0mU4HWgBV5Th6vtiQxPVRxuDE9FQ9bLef3b004rai+YtOk9QotOmdA67ODoDupEDl Tgq+6nPmmpXy+hMhR7oV60dzKM18dADXmh7V+7YoY6wMqqFTN4EfWqeF3t+1HBrrLBkK cZFn/R0BlzqGcTffXyN/acQNtQwzkVRrykwCrfQN5BfRaCdKTOnqxJukimXo0zznzZLq i23pWC4PApQT/eRvdR0IXSPBOU1vbRCcUPgewnK3ilvRT4KycX6ZbhP3+0dVmEdHx9YS N0bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=P7VyUIyVjfG38SPrBq3P+p0ps19raOJyGquUrJEwq7o=; b=l/rc2km1WFFb1xAuGUYHQjZVG3M+K5WGpypchK64J9KRBI4LKeTWH6XtIoIHlz4C9+ r06jNUZS97hmNNNNtKvkvuqmm3IHGZKfwBTVsxoYEXQkh6ov3REeFeUpLzKCWwLwAiUO lEULMoJomgebU4i0KKsHiHDWJxTjcVRNqmYqf4iBLmUKxrR2GlxM24vDw0AY9BoCp/+5 UkKv4ONswq+2McvXn6o13Is3hBVBlI3/BW3nYp8beEqnVkUjs5wJ3v0alkmWTNWHNpZw vKd6NotPr9ifJ6xJTMyqyy7ZGOSA1mltuxeX4cYS/j7DIHrF5IopXZC2eAUO47TOtgRI xiEg==
X-Gm-Message-State: ALyK8tIye5c9jMrT2L13/TzwZn475TfjKoL+qx/aLW4XL7OSKSk3wY0yWAlDstYjDdvoBSBjDzwl3JLOw8TtKg==
X-Received: by with SMTP id j130mr18582243ybj.84.1468734294657; Sat, 16 Jul 2016 22:44:54 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 16 Jul 2016 22:44:25 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Hugo Krawczyk <>
Date: Sun, 17 Jul 2016 01:44:25 -0400
X-Google-Sender-Auth: 9ZSxMo4rbzZK1eO2wv5dciCInMk
Message-ID: <>
To: Eric Rescorla <>
Content-Type: multipart/alternative; boundary="001a113d3e1ce7128e0537ce5949"
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Why is resumption_context hashed?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 17 Jul 2016 05:44:59 -0000


Here are some (second) thoughts on the derivation of resumption_context.

The purpose of this value is to bind the resumed session to the data in the
original connection, namely, to "ClientHello...Client Finished" (and, in
particular, to the server's identity).
The right way to do this binding is by defining
resumption_context = CR(ClientHello...Client Finished)
where CR is a collision resistant function.

This CR can be the TLS hash function Hash or it can be implemented by a
of HKDF computations as currently done.
Specifically, we now have two steps:

resumption_secret = Derive-Secret(Master Secret, "resumption master secret",
                                           ClientHello...Client Finished)
resumption_context = HKDF-Expand-Label(resumption_secret,
                               "resumption context", "", Hash.Length)

Due to the use of HMAC in HKDF, if the underlying Hash is collision
then one can argue that the above two-step derivation is also collision
resistant (as long as there is not truncation anywhere in the derivation

Still, it would be nicer if the collision resistance property would be more
direct/explicit. The most explicit way would be just to define:
resumption_context = Hash(ClientHello...Client Finished).
However, this deterministic derivation from the original handshake
has disadvantages, including possible leakage on the handshake transcript
and the danger of reusing the same value for other purposes.

The next alternative would be to define resumption_context as a "sibling"
resumption_secret, namely,
resumption_context = Derive-Secret(Master Secret, "resumption context",
                                           ClientHello...Client Finished)
This does not make explicit the use of a collision resistant hash function
the derivation but at least shows the direct relationship of
to the handshake transcript. Collision resistance can still be argued on the
basis of HKDF properties.

Finally, we can stick to the current definition which, as said, can be
via collision resistance properties of HKDF, but with one more level of
indirection (and less explicit relation to the handshake transcript).

In all cases, we need some text in the security considerations about the
resistance assumption on HKDF (which is not an integral part of its key
definition); this applies also to the exporter key as mentioned in a
previous email
and any key/value that can be used as a "binding value".


PS: To the question of whether we should apply Hash to resumption_context
concatenating it to other hashes, the answer is that this does not make a
difference. It does not add or subtract from the collision resistance
of resumption_context.


On Fri, Jul 15, 2016 at 7:59 AM, Eric Rescorla <> wrote:

> On Fri, Jul 15, 2016 at 11:39 AM, David Benjamin <>
> wrote:
>> Every time resumption_context is used, it's fed into the PRF hash.
>> Handshake Context gets hashed since that actually expands to the full
>> concatenation and we want to be able to maintain a rolling hash.
>> But resumption_context is always a short value and is already the size of
>> the PRF hash. (If not resuming, it is the zero key, which is sized
>> appropriately. If resuming, it is the size of the PRF hash of the original
>> connection. But we require that resumptions use the same PRF, so that
>> too will be the right size.)
>> Was there some other reason we needed to hash it, or is a guarantee of
>> constant size sufficient to use it directly? If it still needs to be
>> hashed, it seems we ought to redefine resumption_context to be
>> Hash(HKDF-Expand-Label(...)) instead, mostly as a hint to implementors that
>> one may as well store the final value in the ticket.
> I didn't have a good reason. It was just giving me the heebie jeebies
> (technical term) to append something that wasn't hashed to something that
> was.
> -Ekr
>> David
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list