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: > > 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 > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > Attachments: > * 0x5AB2FAF17B172BEA.asc > * signature.asc _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
