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
series
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
resistant
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
process!).
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
transcript
has disadvantages, including possible leakage on the handshake transcript
values
and the danger of reusing the same value for other purposes.
The next alternative would be to define resumption_context as a "sibling"
of
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
in
the derivation but at least shows the direct relationship of
resumption_context
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
argued
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
collision
resistance assumption on HKDF (which is not an integral part of its key
derivation
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".
Hugo
PS: To the question of whether we should apply Hash to resumption_context
when
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
property
of resumption_context.
On Fri, Jul 15, 2016 at 7:59 AM, Eric Rescorla <[email protected]> wrote:
> On Fri, Jul 15, 2016 at 11:39 AM, David Benjamin <[email protected]>
> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>
> _______________________________________________
> TLS mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
>
>
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
