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

[Stephen Farrell <[e-mail]>]

Hiya,

On 02/03/2021 21:49, David Benjamin wrote:
> 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.

Just to note that my main point relates to complexity, and
extension handlers are just one example. If we could agree
that reducing the complexity is an important goal now, that'd
make me happy, regardless of what if anything the spec has
to say about extension handlers. But no harm to discuss that
example too of course (see below).

And to be honest: I am concerned that people want more
complexity and not less, (hi there HRR!) and ISTM that's the
wrong way to go, in this case, and in pretty much all cases
really.

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

So that'd mean if there's any failure processing any inner
extension after decryption in shared mode, then you don't
process any of the outer extensions at all and the server
MUST abort the entire connection as if it had received
gibberish? I guess the spec might need to say what error
to send in that case as otherwise we'd maybe be leaking
info as to what bit of the inner was dodgy?

> 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 also another extension-related issue: with 20+
extension types, some of which are inter-related, and
with compression options, that's a crap load of testing
to do. We could reduce that a lot if we ditch the
compression and e.g. state that one should follow the
design above for shared mode.

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

Complicated, and not much use I think. An early assertion
I think I recall being made about ESNI was that it's size
didn't matter so long as the CH fits into one packet. Now
we seem to have reversed ground on that, at significant
expense in terms of complexity and for probably <100 octets
out of about 600.

I'd argue to just ditch this near-compression until we
really have a CH that's a few packets and then try figure
it out.

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

pqkeyshare.see_outer could be a hash of the PQ share from
the outer. Point is: we can leave that 'till later, we don't
need it yet.

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

I'm not convinced TBH, but you might be right. Seems though
that dichotomy might omit library clients which likely do
differ.

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

Right. I'm not sure what info that might leak though.

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

Bullet point 7 of page 13 of -09.

> This came up in
> https://github.com/tlswg/draft-ietf-tls-esni/issues/389, which was closed.

That GH issue may be closed but this wasn't discussed on the
list, and its not clear Martin was raising this exact topic,
(that I did raise in that GH issue without getting any
substantive response at all), and the above text is still in
the editor's draft, and it's the wrong text, and I still have
no plan to implement it. So I don't care if the GH issue is
closed or not:-)

S

> 
> David
>