Thanks for writing this up! We've been pondering this subject as well, as part of identifying places where ECH and QUIC interact interestingly. (The other being the padding issue in https://github.com/tlswg/draft-ietf-tls-esni/issues/264.)
As with the padding issue, QUIC replaces the record layer, so all the handshake/record-layer coordination here must cross the TLS/QUIC public API. TLS must configure two different keys for QUIC, then QUIC must trial decrypt and report back to TLS which keys were used. In contrast, something that lives entirely in the handshake should apply to QUIC without modifications. I think in essence we’re running into QUIC sandwiching itself between the TLS handshake and records layer, despite that “interface” not being quite fully understood yet. (I'm not sure what's IETF email etiquette for joining related WGs to an existing thread, so I'll forward this separately to the QUICWG, so they can join the discussion.) David On Mon, Aug 17, 2020 at 4:55 PM Christopher Patton <cpatton= 40cloudflare....@dmarc.ietf.org> wrote: > Hi list, > > In the current ECH specification (draft-ietf-tls-esni-07), the server > provides no indication of whether the inner or outer ClientHello (CH) was > used. This means the client must do trial decryption to make this > determination, which creates implementation complexity and potentially > raises security concerns. I was hoping to get your thoughts on a couple > alternatives, which strike different balances between implementation > complexity and other design considerations for ECH. Follow along here: > > https://github.com/tlswg/draft-ietf-tls-esni/issues/274 > > Thanks, > Chris P. > > > _______________________________________________ > 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
