Hiya list, [Re-sending this email with a subject. Apologies for the spam!]
Chris Wood plans to publish the next draft of the ECH extension by the end of the week (or early next week). As such, I wanted to give you all a brief run-down on the open issues, some of which won't be resolved until a later draft. The numbers below refer to GitHub issues: https://github.com/tlswg/draft-ietf-tls-esni/issues We would like to resolve the following before -08: #323: Replace "inner_digest" mechanism with authentication of ClientHelloOuter. In case of ECH acceptance, the only part of the ClientHelloInner that is authenticated are the outer extensions incorporated into the ClientHelloInner. David Benjamin contributed a PR that sets the associated data for AEAD encryption to the ClientHelloOuter (sans the ECH extension). This was previously not possible because of PSK binders in the ClientHelloOuter. This is no longer an issue, however, since we decided at Interim 2 to disallow session resumption in the ClientHelloOuter. PR: https://github.com/tlswg/draft-ietf-tls-esni/pull/336 #325: The server shouldn't change its mind about ECH usage after HRR, since switching from ClientHelloInner to ClientHelloOuter (or vice versa) could trigger yet another HRR. https://github.com/tlswg/draft-ietf-tls-esni/pull/339 There remain at least two problem areas, which won't be resolved until after -08. #233, #333: Our experience with implementing ECH has shown that HRR behavior still needs to be fleshed out. First, the client needs to ensure that HRR-sensitive parameters match in the ClientHelloInner / ClientHelloOuter. While it's fairly straightforward to get this right, there are tons of ways in which implementations can get this right. We would like to provide guidance on this (#233), but saying which parameters are "HRR-sensitive" and which aren't is not straightforward. Chris Wood has a PR for this, but we don't yet have consensus on it. Second, the server needs to ensure that ECH usage doesn't change across the HRR. This is straightforward for stateful-HRR servers (#325), but we have not yet specified how stateless-HRR servers should do this. In fact, it's uncertain how stateless-HRR would work in Split Mode at all (#333). PR: https://github.com/tlswg/draft-ietf-tls-esni/pull/316 #264: Replace record-level padding with handshake-level padding in order to resolve API-mismatch issues for QUIC. There's a PR for this, but we don't yet have consensus on it. PR: https://github.com/tlswg/draft-ietf-tls-esni/pull/313 Best, Chris P.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
