Subject: [TLS] ESNI/ECHO updates

From: Rob Sayre <[email-masked]>
Date: Fri, 14 Feb 2020 16:17:29 -0800

Hi,

Are there any updates to ESNI/ECHO to share as a draft or an update?

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

thanks,
Rob

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Feb 2020 13:00:53 +0000

Hiya,

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Christopher Wood" <[email-masked]>
Date: Sun, 23 Feb 2020 19:57:24 -0800

Sorry for the delay in updating you (and others). Here’s the current status. 

We’re actively analyzing ECHO. As of now, we expect this to complete in March, unlikely before the Vancouver meeting. No red flags have been discovered thus far. However, we are updating the tunnel PR and hope to post (and merge) it before the deadline. That will give folks enough time to update implementations and discuss any remaining issues before proceeding with the document.

Best,
Chris

On Mon, Feb 17, 2020, at 5:00 AM, Stephen Farrell wrote:
> Attachments:
> * 0x5AB2FAF17B172BEA.asc
> * signature.asc

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Feb 2020 09:35:58 +0000

Hiya,

On 24/02/2020 03:57, Christopher Wood wrote:
> We’re actively analyzing ECHO. As of now, we expect this to complete
> in March,

I would welcome seeing that done in a more open
manner.

S.

---

From: Rob Sayre <[email-masked]>
Date: Mon, 24 Feb 2020 12:26:03 -0800

> I would welcome seeing that done in a more open

I took this to mean a ProVerif model--something like this:
https://github.com/chris-wood/encrypted-sni-model/blob/master/stable/esni_analysis_00.pdf

If that's what's going on, I don't see too much value in doing this work in
public, provided the WG can iterate a bit afterward. Maybe even check it in
to the tlswg repo when it's ready.

thanks,
Rob