Subject: Re: [TLS] (no subject)

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Mar 2017 17:29:04 -0800

Based on people's seeming mild preference for option #1, I have produced:
https://github.com/tlswg/tls13-spec/pull/901

I'll merge this tomorrow absent some loud screaming.

-Ekr

On Thu, Feb 9, 2017 at 1:17 PM, Eric Rescorla <[email-masked]> wrote:

> Hi folks,
>
> We need to close on an issue about the size of the
> state in the HelloRetryRequest. Because we continue the transcript
> after HRR, if you want a stateless HRR the server needs to incorporate
> the hash state into the cookie. However, this has two issues:
>
> 1. The "API" for conventional hashes isn't designed to be checkpointed
>    at arbitrary points (though PKCS#11 at least does have support
>    for this.)
> 2. The state is bigger than you would like b/c you need to store both
>    the compression function and the "remainder" of bytes that don't
>    fit in [0]
>
> Opinions differ about how severe all this is, but it's certainly
> unaesthetic, and it would be nice if the state that was stored in
> the HRR cookie was just a hash output. There seem to be three
> major approaches for this (aside from "do nothing").
>
> 1. Special case HRR and say that the transcript is either
>
>    CH || SH ....   (no HRR)
>
>      or
>
>    Hash(CH1) || HRR || CH ... (HRR)  [1]
>
>
> 2. Pre-hash the messages, so that the handshake hash
>    becomes:
>
>    Handshake_hash_N = Hash(Hash(msg_1) || Hash(msg_2)
>                            ... Hash(msg_N))
>
> 3. Recursively hash, so that the handshake hash becomes:
>
>    Handshake_hash_N= Hash(Handshake_hash_N-1 || msg_N)
>
> [As Antoine Delignat-Lavaud points out, this is basically making
> a new Merkle-Damgard hash with H as the compression function.]
>
>
> I've posted PR#876, which implements version #2, but we could do any one
> of the three.
> and they all have the same state size. The argument for #1 seems to be
> that it's the minimal change, and also the minimal overhead, and the
> argument against is that it's non-uniform because CH1 is treated
> differently.  We might imagine making it seem more uniform by also
> hashing HRR but that doesn't make the code any simpler. Versions #2
> and #3 both are more uniform but also more complicated changes.
>
> The arguments for #2 versus #3 are that #3 is somewhat faster
> (consider the case where you have a short message to add, #2 always
> needs to run the compression function twice whereas #3 can run it
> once). However, with #3 it is possible to take a hash for an unknown
> transcript and create a new hash that matches that unknown transcript
> plus an arbitrary suffix.  This is already a property of the M-D
> hashes we are using but it's worse here because those hashes add
> padding and length at the end before finalizing, so an extension
> wouldn't generally reflect a valid handshake transcript, whereas in
> this case you get to append a valid message, because the padding is
> added with every finalization stage. I don't know of any reason
> why this would be a security issue, but I don't have any proof it's
> not, either.
>
> I'd like to get the WG's thoughts on how to resolve this issue over the
> next
> week or so so we can close this out.
>
> -Ekr
>
> [0] The worst-case overhead for SHA-256 is > 64 bytes and for SHA-512
> it’s > 128 bytes. The average is half that.
>
> [1] We actually need to do something to make it injective, because
> H(CH1) might look like a handshake message, but that should be easy.
>
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 Mar 2017 12:50:03 +0100

> the hash state into the cookie. However, this has two issues:

Isn't the whole CH2 supposed to be deterministically created from CH1 and HRR?

So you should be able (as the server) to recreate the CH1 given the hash (or 
better yet, keyed HMAC) of the CH1 fairly easily? Bonus point: you 
automatically reject technically malformed CH2 messages (ones with more 
changes than prescribed) as you won't be able to create a CH1 that creates the 
matching HMAC.

I do not think that stateless HRR is special enough to mess around with 
message transcript hash...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 9 Mar 2017 14:41:08 +0200

> Isn't the whole CH2 supposed to be deterministically created from CH1 and HRR?

No.

Neither CH1 nor CH2 are deterministic w.r.t. one another.

> changes than prescribed) as you won't be able to create a CH1 that creates the 

Actually, you can't create CH1 from just CH2. Back some versions it was
merely very annoying to do so, now (as in -18), you can't do it at all.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Mar 2017 16:58:59 -0800

Landed.

Also, see the follow up PR to make implementation easier:
https://github.com/tlswg/tls13-spec/pull/904