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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
