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

[Stephen Farrell <[e-mail]>]

Hiya,

Since I was logged into the github web site (as happens
occasionally but not often) and as requested at the TLS
session, I translated the text below into github issues
in the hope that they might be included in discussion.
Links to each below.

On 28/02/2021 17:34, Stephen Farrell wrote:
> 
> 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.

https://github.com/tlswg/draft-ietf-tls-esni/issues/401

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

https://github.com/tlswg/draft-ietf-tls-esni/issues/397

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

https://github.com/tlswg/draft-ietf-tls-esni/issues/399

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

https://github.com/tlswg/draft-ietf-tls-esni/issues/398

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

https://github.com/tlswg/draft-ietf-tls-esni/issues/400

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

https://github.com/tlswg/draft-ietf-tls-esni/issues/396

Cheers,
S.


> 
> - 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.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>