Re: [TLS] implementing ESNI/ECH draft-09

[David Benjamin <[e-mail]>]

On Sun, Feb 28, 2021 at 12:35 PM Stephen Farrell <[e-mail]>
wrote:

> - 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.
>

I agree calling extensions handlers twice would be problematic, but it
seems to me that's not necessary. The spec conceptually splits ECH into a
client-facing server and a backend server which I think, even for "Shared
Mode" implementations, hints at a cleaner implementation strategy:

Early in the handshake, before even version negotiation (as section 7.1
says) and certainly before calling any extensions handlers, see if there is
an ECH extension in the ClientHello. If so, attempt to decrypt the inner
ClientHello. If you succeed, continue the handshake with the inner
ClientHello. If you fail, continue the handshake with the outer
ClientHello. Ignore the ClientHello you didn't use.

This way you only run the complex stateful handshake logic on one
ClientHello, since that's logically the "backend server". The
"client-facing server" is really just a ClientHello dispatcher that needn't
interact with most of the handshake.

- 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.
>

Yeah, the compression mechanism is a bit complicated. I don't think "see
outer" in the extension definition is the right path. It would likely
introduce ClientHello malleability problems (see
https://tools.ietf.org/html/draft-ietf-tls-esni-09#section-10.10.3), unless
the extension further defines how to "compile out" out the "see outer"
portion.

Rather than exposing the details of the compression to the API, I think
it's better to reason about what is public, what is private, and what are
the goals of the wire image. It seems to me we have roughly two kinds
of clients to consider:

First, there are clients that send GREASE and wish to align their ECH and
non-ECH ClientHellos as much as possible. Those clients will likely send
the bulk of their extensions in ClientHelloOuter as most do not depend on
the server name. E.g. a browser always sends ALPN={h2,http/1.1}. There, the
default is to reference the extension, so the encrypted payload only
contains the couple of extensions that vary (SNI, PSK). Keeping that small
is good for bandwidth not just in ECH connections, but also to avoid an
overly expensive GREASE payload in non-ECH connections. Keeping the two
ClientHellos aligned also simplifies the rest of the handshake: you only
have one set of preferences to evaluate the server response against.

Then there are clients that don't especially care about their wire image.
They may instead send a minimal ClientHelloOuter, just enough to
authenticate a replacement config. (Or maybe they don't care about the
recovery flow at all and don't even do that.) Those clients will likely
send the bulk of their extensions in just ClientHelloInner, and omit them
from ClientHelloOuter altogether. There are a few extensions (key_share,
signature_algorithms, etc.) that are necessary in a minimal
ClientHelloOuter, so they may compress those still. Though this does give
outer and inner paths wildly different preferences, so the client needs to
modify the handshake accordingly.

Probably the way to simplify, in both spec and implementation, is to focus
on those two kinds of clients.


> - 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?
>

Yeah, constant-time seems a bit hopeless here. The point of ECH is to
protect sensitive fields in the inner ClientHello, but those sensitive
fields result in a choice of different extensions, certificate, and private
key in the server. That's going to result in a wildly different instruction
and memory access trace.


> - 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.
>

Is there such a requirement? I didn't think there was. This came up in
https://github.com/tlswg/draft-ietf-tls-esni/issues/389, which was closed.

David