On 6/2/2020 11:30 AM, Stephen Farrell wrote: > Hiya, > > Sorry if I'm missing a bit of context... > > On 02/06/2020 18:28, Christian Huitema wrote: >> clients prevent server identification by sending >> an empty record_digest field in the ClientEncryptedCH, and > That seems to me to be an unnecessary breach > of the do-not-stick-out requirement. In my code > it was quite easy to attempt trial decryption > (if so configured). I don't think there's an > expectation of a use-case where the number of > keys in use would be so high as to cause a problem. > So I'd prefer the client in that case to just > send random data of the usual length. > > That said, ECH is sticking out a lot already > so this is not a huge deal;-)
I see your point, Stephen. Length=0 is a clear signal to the server, so server processing is just a bit easier than sticking a random number that looks like a SHA256 hash, or whatever the cipher-suite mandates. With length=0 third parties can casually observe that "this server wants to remain private"; with random numbers they can only observe that the record digest does not match any of the digests that they are tracking. Random numbers are thus a little bit better for privacy, at the cost of a little bit more work for the server. As I said, my first goal is to avoid silly interop issues and have a recommended behavior for servers that desire privacy. Chris is nudging me to create a PR; If the consensus is for random numbers, I will put that in the PR. -- Christian Huitema
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
