Re: [TLS] ESNI/ECHO updates

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/02/2020 00:17, Rob Sayre wrote:
> Hi,
> 
> Are there any updates to ESNI/ECHO to share as a draft or an update?

I'm also interested:-)

> 
> It's been a few months, so just wondering (even if there's not much to say).

I did some initial hacking on a branch of my openssl fork
to see how hard the inner CH stuff might be. [1] Turns
out it's doable but there are some wrinkles with handling
extensions that might be good to discuss on the list to
improve our chances of interop.

There are some notes at [2] - the ones I think might
benefit from list discussion are:

- PSKs - I ended up just putting the PSK extension in
the inner CH (with binder calculated over the inner CH)
and putting no PSK extension in the outer CH at all.
That seems right for tickets, but I'm not sure for
cases where the PSK isn't a ticket. Trying to support
PSKs in both inner and outer seems pretty complex and
likely hard to use as well.

- I'm not sure what to do about the TLS key share
(and supported groups) - in principle it might make
sense for those to vary between inner and outer CH, but
that'd not be very useful today, and could need a lot
more code changes (I've not yet played with it) - if
it made sense to punt on that for the first version of
an ECHO RFC and just say different key shares MUST NOT
be used in inner and outer that might be good, even if
it's a little smelly. OTOH, it might be better to bite
the bullet now, for better support for the split mode
scenario, e.g. if the "front" server had more up to
date algorithms or something.

- I implemented support for varying ALPN between inner
and outer and that wasn't hard and seems to make sense.
A consequence is that the EncryptedExtensions with the
ALPN from the server then also need (record layer)
padding. Hopefully, supporting different inner and
outer ALPNs doesn't need much list discussion but it
would be a change from earlier drafts. And one might
wanna put something in the HTTPSSVC or ESNIConfig for
this I suppose, not sure.

- inner CH padding - we're no longer just padding the
(E)SNI but the entire inner CH so the padded_length in
the ESNIConfig kinda makes (even:-) less sense to me.
I'm not sure if padding the outer CH is still needed
for something though.

Note that I've only looked at the extensions supported
by the OpenSSL build I'm using - there are some more
in the IANA registry that might or might not need a
bit of thought. And there are a bunch where it might
(in principle) make sense for 'em to vary between
inner and outer CH, but where I suspect there'd not
be enough payoff to call for it to be supported.
(Some of those are noted at [2].)

Cheers,
S.

[1] https://github.com/sftcd/openssl/tree/encch
[2]
https://github.com/sftcd/openssl/blob/encch/esnistuff/echo.md#extension-specific-handling

> 
> thanks,
> Rob
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>