Re: [TLS] ECH usage indication: alternatives to trial decryption?

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.com@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
>