Re: [TLS] TLS ECH, how much can the hint stick out?

[Christian Huitema <[e-mail]>]

On 9/11/2020 4:20 PM, Karthik Bhargavan wrote:

> Ok, in that case it is worth making the don’t “stick out” property
> more precise.
>
> 1) We can either try to prevent the attacker from learning whether ECH
> was actually used in a particular connection, or
> 2) We can try to prevent the attacker from learning whether the server
> supports ECH at all.
>
> I gather the consensus is that we should try to obtain (2) at least
> until ECH support becomes ubiquitous on the server side?
> Since TLS 1.3 moves all but a few SH extensions to EE, I suppose there
> isn’t any other extension to hide this signal in.
>
> In that case, I guess using a value derived from the handshake key as
> part of the ServerRandom should probably work.
> That is, when constructing the ServerHello:
>
> - first set the first N bytes of the server random to 0
> - compute the hanshake secret (based on either the inner or outer CH)
> - compute the signal of N bytes as
>   signal = HKDF-Expand-Label(handshake secret, “s hs hmac”,
> Transcript-Hash(ClientHello..ServerHello), N)
> - replace the first N bytes of the server random with signal
>
> This is a somewhat icky design, but I think we should be able to
> justify it for (say) N <= 16 bytes.

I like that design a lot. It is more robust than my proposal to mix the
key share in the hint.

In other words, makes the hint dependent on the actual handshake secret.
That's pretty much what I was aiming for when asking to make the hash
dependent on the key components of the handshake secret. I was concerned
with a potential circular dependency between the secret, the hint and
the server random, which is why I was looking at mixing various elements
in the hash that computes the hint. But Karthik is of course right, the
handshake secret itself does not depend on the transcript; that
dependency is only introduced when the label is derived.

Any big issue keeping N=8?

-- Christian Huitema