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

From: Christopher Patton <[email-masked]>
Date: Mon, 17 Aug 2020 13:54:51 -0700

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.

---

From: David Benjamin <[email-masked]>
Date: Mon, 17 Aug 2020 17:21:10 -0400

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=
[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>