tree ba3c4bd413bd0fb65617e52d100dafaec57d75ef
parent 43ab56c618fc5212e36b9e20ad48549d3bbcc0ec
author David Benjamin <davidben@google.com> 1621532545 -0400
committer David Benjamin <davidben@google.com> 1623277936 +0000

Compute the ECH GREASE payload outside of the callbacks.

This is kinda annoying and, like the grease_seed, demonstrates a
shortcoming with the idea of making add_clienthello completely const.
Strictly speaking, we only need idempotence. But I think this is okay:
const is much easier to enforce than idempotence, and we'll likely need
to do this anyway:

- While not in the current draft, I expect the draft's eventual HRR
  resolution to retain the ECH extension, GREASE or not, on ECH reject.
  Things are somewhat violating RFC8446 HRR rules right now. That means
  we'll need to stash the ECH payload regardless.

- ECH binds all the other extensions in the outer ClientHello, so
  computing the payload will need to move outside the callback system
  anyway.

In some sense, all this is shifting our ClientHello output from the
"immediate mode" end of the spectrum (as we usually use) to the
"retained mode" end, which I suppose makes sense as this message becomes
more intricate.

Bug: 275
Change-Id: I9eb8cd1cde2ce264345b6ed3ee526d4eab81e911
Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/47990
Reviewed-by: Adam Langley <agl@google.com>