[TLS] (no subject)

Christopher Patton <cpatton@cloudflare.com> Wed, 14 October 2020 23:32 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 C20B73A1141 for <tls@ietfa.amsl.com>; Wed, 14 Oct 2020 16:32:55 -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 GXmJhz0XnfT6 for <tls@ietfa.amsl.com>; Wed, 14 Oct 2020 16:32:54 -0700 (PDT)
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 251873A113D for <tls@ietf.org>; Wed, 14 Oct 2020 16:32:53 -0700 (PDT)
Received: by mail-qv1-xf2d.google.com with SMTP id ev17so398190qvb.3 for <tls@ietf.org>; Wed, 14 Oct 2020 16:32:53 -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=Kll8nJJBFO0N+HJFhvk/NnVJtBU72LWMYc97tD1AnzE=; b=YXnpcAAadt2v7bw2GhNp6GNBcIDt1MDFvdg7Q7CjAhhuo1B4wXDLTaiZGFdksgAZeI r4psuJcxp8iqLviYYjmUr9iyND3o7FB21w7bulyzb75b43m296vcz1F8Hx7F2HjV2Pbu gNwmiCR04Edz0IpcHABBL5/ifSjVdRPiPrVs4=
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=Kll8nJJBFO0N+HJFhvk/NnVJtBU72LWMYc97tD1AnzE=; b=hHFaGra9nFrnoM1gRKbZPbkwtV155LDC/FG4yQYqgM0LA6stONLL+2kuWXtQi1/0Q0 zjoZuIk5e36wUrgux0s8hVdIn9/7tqZlSXqvqjnQpf0uR7Z+xoNMRKXBu/pTtEkaLQdB 7c8wDpaMucumQwZVoaiQ0YZ+kuL7AGmhjuVQLBPd1BqZ8I2p/+Vm4bjRUQuA+Aw5lph9 si6qzvCRYDX2YE1k7ly8n7ZTKAiDPj8mEKfQ8C73L0+Yoc9RsIOOb8BGSkstQbbfN4TJ T9Rzv17Tbl8RQL7rpMad73Pn5fwhfpdnRiRg7FqtbGOXjmhQrwhb75Yjhqaun625Y9F+ YHhw==
X-Gm-Message-State: AOAM532Cc7cPGiHYoFPK25nPx/1W7Lz5VTpvKRaS8K40iLv/VxEADL22 pSkyhDbU/JWvV9wDIFxqvwjHK4XmT8NEeaptY5SKaPU/sdU=
X-Google-Smtp-Source: ABdhPJyoHtXQVArTOLm4HsLU5wxBGDz2aAjdTcwr7QBXOeDvX8bWzVRzN++GW9uDC+e38qN4R/pRQIfKsboM5fpy8XM=
X-Received: by 2002:a0c:a046:: with SMTP id b64mr1994780qva.55.1602718372774; Wed, 14 Oct 2020 16:32:52 -0700 (PDT)
MIME-Version: 1.0
From: Christopher Patton <cpatton@cloudflare.com>
Date: Wed, 14 Oct 2020 16:32:42 -0700
Message-ID: <CAG2Zi22Xdh3N-UkYU7eT1Qou_ZkY4outjH337Hh_WJD9dyhn=Q@mail.gmail.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000048e59705b1a9f30a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bYtLM9ayFHBXJhGFbGVTGzFnx7c>
Subject: [TLS] (no subject)
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:32:56 -0000

Hiya list,

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.