[TLS] Outstanding issues for ECH

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

Return-Path: <cpatton@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2B5883A1147 for <tls@ietfa.amsl.com>; Wed, 14 Oct 2020 16:36:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id cj4wyk0IiQpg for <tls@ietfa.amsl.com>; Wed, 14 Oct 2020 16:36:31 -0700 (PDT)
Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657B83A1143 for <tls@ietf.org>; Wed, 14 Oct 2020 16:36:31 -0700 (PDT)
Received: by mail-qv1-xf2e.google.com with SMTP id b10so405022qvf.0 for <tls@ietf.org>; Wed, 14 Oct 2020 16:36:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=WOuKm+QFAPJqlTfRS7jnAPEzjnOy9wqYZm1EoeNuALk=; b=igeoizRcZcc2NCsan87Yu1ZVefSobAEhN9F/lAC4WbdJ+qhZ2xjko8SGsv1QRQDRwg nXtmGseZuR6setgXVNH68IltC/sIfaDRC0KHuANqMiDXjo0BlMHThAKNX7dzHPVqttld UmlBW3BqSoLDD/nCCvbOz31ZxiU1tajQupFLI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WOuKm+QFAPJqlTfRS7jnAPEzjnOy9wqYZm1EoeNuALk=; b=n36oqv+wHC9rkvJPrJeKg9s5EJNfYsZwc85MxfAumlV/89ZdrjzSjhFAiz9S/EV+rF 0NMVCJcMfQ4l7XG7F2HzkfSXL9cE6Kup20LxK1eUpHlnzHnXKGxZVX+muM3Ry4EOop7V IMES3W9JFK3wGjBvTBsaYTK4v4rB4oc+cuU0+x5ocsoBA4CMJeopx9anl6Ptgq9YjACq xbjco6yTVVhgu+oky2NVLF5Vq6fAukhv0ufRGWebD3asI7E6oZ8JLDnP8ktFQpq+BrSl rWA+utLKPWH9j07XuN+joK/wRkVJsA6cBHo6ylsjymluQ5/p4+wV5hKts3kxqBOjuZga BRiA==
X-Gm-Message-State: AOAM532FMhcjdegrP87/v6dc4eNPcauiUee5Ldb8kRAsz5e4CnlhEpgc 3AlwdOQLem/Mjw5PnMfWD6D31OlKKGr4KXASInQY9ufTtsf/eg==
X-Google-Smtp-Source: ABdhPJyu4ck5mqNW89wcfqz3skl4zONl8aVdwRGRngjbwfUskAAzseJBOomk+8RJXoZwK5dLJ7LaMh4lL8w1pZkIF5o=
X-Received: by 2002:a0c:d682:: with SMTP id k2mr1924301qvi.27.1602718590161; Wed, 14 Oct 2020 16:36:30 -0700 (PDT)
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
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 23:36:33 -0000

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:

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:

#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.

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:

#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:

Chris P.