[TLS] Outstanding issues for ECH

Christopher Patton <cpatton@cloudflare.com> Wed, 14 October 2020 23:36 UTC

MIME-Version: 1.0
From: Christopher Patton <cpatton@cloudflare.com>
Date: Wed, 14 Oct 2020 16:36:19 -0700
Message-ID: <CAG2Zi21Ponj0Y6+-DeFc=DCuGwto3O055s9y8Wtzds+7wi=-OQ@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003dffa605b1aa002e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/T-uecMa7QRjT-2_Qkj03KiEHhZo>
Subject: [TLS] Outstanding issues for ECH
Precedence: list

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] Outstanding issues for ECH Christopher Patton