[TLS] implementing ESNI/ECH draft-09

[Stephen Farrell <[e-mail]>]

Hiya,

I've just got my OpenSSL code "working" for draft-09.
The s_client and s_server talk to one another and do
ECH; NSS's tstclnt talks to my s_server and does ECH
and my s_client talks to cloudflare's test server and
does ECH. So this can be made work, which is the good
news. (Thanks to Martin Thomson and Chris Patton for
help in getting that done btw.)

Note that the scare quotes on "working" above are
because the code I have now is horrible and needs a
lot of re-factoring but I'm not keen on doing that
yet if we're considering further breaking changes
that might add more horror;-)

I have the following specific comments having done
this:

- This is *much* harder to implement compared to ESNI as
   it interacts with the rest of the TLS stack/library in
   many more ways. It should be an explicit goal to reduce
   that complexity IMO and not increase it further.  That
   complexity leads to *many* new failure modes that not
   everyone will get right, e.g. incorrect encoding of inner
   extensions, extension handlers that have side-effects
   being called twice etc.
     - Possible fix: organise an interim session (or slot
       therein) with the explicit and only goal of
       simplifying ECH.
     - Possible fix: publish test vectors and require a
       test vector from anyone proposing any new construct,
       before accepting their suggested new crypto-wrinkle.
     - Possible fix: make the spec much more explicit about
       what goes into the transcript at every possible
       stage, esp when that changes.

- Including the client-sender's ephemeral public key in
   the AAD means clients cannot use a single-shot HPKE API.
   That then means that the client key pair has to be
   separately generated and held onto until HPKE encryption.
   It'd be a good bit better and simpler were that not the
   case and a single shot HPKE encrypt API could be used
   witout exposing that key pair to the stack.
     - Possible fix: having a value linked to the inner
       plaintext could suffice maybe?

- The SH.random magic confirmation value interacts with
   ticket handling on the server in some ways I don't yet
   understand fully. Messing with the lower 8 octets there
   also breaks internal OpenSSL APIs for handling packets
   but so do other parts of ECH, so that might be fixable.
     - Possible fix: re-consider the use of SH.random as a
       signal - ECH sticks out in the outer CH anyway, so
       maybe return an ECH in the SH with a value that does
       the same trick so the observer can't tell from the
       SH if it was a successful use of ECH, grease or a
       failure in ECH.

- There's no simple, sensible way to decide which
   extensions to "compress" in the inner that I can see. As
   a library, one could come up with some vastly complex API
   to allow applications pretend to handle this, but that'd
   seem more dangerous than useful. While I made the code
   generic, it's not at all clear that'll ever be useful.
     - Possible fix: forget generic compression and define
       a small set of extension types that can be inherited
       from the outer with all others being present as
       needed in inner and outer. For future extensions
       (e.g.  some many-octet PQ key agreement), have the
       extension definition include the option of "see
       outer" within the extension encoding.

- Given inner and outer can have different sets of
   extensions, I guess there'll never be a way to make ECH
   handling constant-time. If so, then that ought be covered
   as a security consideration. If not, how'd that work?
     - Possible fix: document potential consequences of
       ECH never being constant time?

- I don't plan on implementing the "MUST check
   outer.sni==public_name" check ever really. (Unless
   forced to as part of upstreaming maybe.)
     - Possible fix: remove that MUST.

- I've not implemented padding, nor attempted to make
   greasing as complex as called for, so don't yet have
   comments on those features as they are in -09.

There are probably other times when coding this up where
I swore at the spec text but I've forgotten so maybe those
weren't so bad in the end:-)

Cheers,
S.