bug: configuration for GREASE ECH parrot for Chrome 120 doesn't match BoringSSL about utls

[gaukas]

Possibly we could add a function in u_ech.go named BoringGREASEECH() which returns the GREASE ECH generated by BoringSSL? (Instead of hard coding them in each parrot based on BoringSSL)

[hax0r31337]

I have reviewed the code of NSS, which is the TLS library that Firefox uses.

It also only selects AEAD between AEAD_AES_128_GCM and AEAD_CHACHA20_POLY1305, but randomly.

aead = (rawData->data[0] & 1) ? HpkeAeadAes128Gcm : HpkeAeadChaCha20Poly1305;

https://github.com/mozilla/gecko-dev/blob/8b5d93d099b5b501cf5bd2b606c59afcf88bef1c/security/nss/lib/ssl/tls13ech.c#L2226

And the GREASE ECH Payload size does not have a fixed size, as it was generated based on the outer ClientHello.

[hax0r31337]

By random sampling, the payload size of the GREASE ECH Extension in Firefox would be 223 (+16)

[gaukas]

Thanks for doing these. I will take a look. I am pretty sure I saw a shorter ECH payload at some point from my Firefox...

[gaukas]

Checked again, did not find sizes other than 239. Seems I made a mistake. Now I think this issue has been fully addressed and can be closed.

[gaukas]

Great observation.

why utls parrot also candidates AEAD_AES_256_GCM.

I did not explicitly refer to BoringSSL in terms of adding ECH to Chrome/Firefox parrots, but rather referred to the RFC which mentions GREASE ECH should try to randomly select from all supported combinations. So this is indeed an oversight.

BoringSSL pads payload not only from 128, 160 but 128, 160, 192, 224 according to code below.

Thanks for the observation, I did not go through the code but instead randomly sampled for ~10 GREASE ECH generated by Google Chrome, which did not really include these many possible lengths.

Should you open a pull request to address these problems, it would be wonderful.

[gaukas]

A similar patch, based on either random sampling or code review of Firefox might be needed as well.