Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt

Christopher Wood <> Tue, 02 June 2020 18:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C93733A0EB7 for <>; Tue, 2 Jun 2020 11:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=Kebwutzo; dkim=pass (2048-bit key) header.b=d8VDLtAH
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EHmLr6TBKxnk for <>; Tue, 2 Jun 2020 11:19:31 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D88503A0EB3 for <>; Tue, 2 Jun 2020 11:19:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 241DF5C010C; Tue, 2 Jun 2020 14:19:30 -0400 (EDT)
Received: from imap4 ([]) by compute1.internal (MEProxy); Tue, 02 Jun 2020 14:19:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=mDDPP LRFV1HjSjPMp8/eEiu0KPg27AS2tVJwbotIW4I=; b=KebwutzohYn36QqF5aU76 hub7kxk2JS9C/Ne8hBWijT3Z/f1JOKMR/NOpGQg/ROW8R34MB2uyc3TV30skM509 kTIFJ1OAQPSEZgX7uY08G6RDsKhf5AwrpH4C+NUpqlWDEcGjWsjYzDpIuj1/ELxT nWN4UO5oETsl6riKCyAb0yKsj37JcDuUN8mpYJ8HHnl8Ul+ncFvYy8qa3kUsZShT dN5wKfutcAX4VgFdaTKgHeLzZaRE7BFB+HANIDzwk3phuUJkuKwsXSthuRYLWI8s t4UvBr25NzAKBFS1jMw6tFCm8i3qkvMlZS8WxLLgSCrp4cES8pCTAOavvl5WUYpa g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=mDDPPLRFV1HjSjPMp8/eEiu0KPg27AS2tVJwbotIW 4I=; b=d8VDLtAHjHcGQaIkVGPK3k/u/uJKJ82my1DmDMbWrAXvt2j69j/e46xBe p7KXMPgtboYWVd1MpI6G16sqnt/9B29YbZ/MPkdvlR8lulnlghT38zswFKX1lv/c mL5I+PYgPW/3b+vuoUZy/agtJ2BhYtTkkALBslKqCEMWWs7xuHbm8ja6idGNDWNN yUrcvpqwENdWLdcdrxBBsq1fcmtwPbsClxxQVcKFZx4XupyESIFb6i4Qj5FogdFj xxymjZ/nfzXWTGHjntO0PewgGpu4RKNYlgezB5bwwJ9QT8M01ctfNWOQwB6j6aFN 0O4CHhzYjXxy38g4Ty9bq3ASnrbUA==
X-ME-Sender: <xms:MZjWXoACGQ44Xn75otEG17c6_Eb2sNEiYTXig9hs3FCm_ud6ugd2Og>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudefjedgleegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfvehh rhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvg htqeenucggtffrrghtthgvrhhnpeekffekveeghffgtdffieevudfgledthefhfedvvdeh leeivdegveegleefteejudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght
X-ME-Proxy: <xmx:MZjWXqgs2w7sC8fWNiGgwtDUeNZ6scpWZS9bFXxUKf85LWuOmxUtpg> <xmx:MZjWXrlLsQ-NKO3Ey2zG-dCQfgGGZshPcbh0ZxmEeMzYqlZ7QPt7Kg> <xmx:MZjWXuzf9HnO_TsCAzjh5YWb-6IBeITw5HRhvd1E9fFVZfhsskVzBA> <xmx:MpjWXkc9l8ImdjLZ_XR2w2Qe8tCC7zF7EW73OCA6-3BRe-tGP1G1Uw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A98DB3C00A1; Tue, 2 Jun 2020 14:19:29 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 02 Jun 2020 11:18:35 -0700
From: Christopher Wood <>
To: Christian Huitema <>, "" <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Jun 2020 18:19:33 -0000

On Tue, Jun 2, 2020, at 10:28 AM, Christian Huitema wrote:
> On 6/2/2020 5:44 AM, Christopher Wood wrote:
> > On Mon, Jun 1, 2020, at 10:06 PM, Christian Huitema wrote:
> >> This draft looks really good. I just have two questions of clarification.
> I am not sure that I understand the point made in appendix B, Total 
> Client Hello Encryption. The text in that appendix explains that "The 
> design described here only provides encryption for the SNI, but not for 
> other extensions, such as ALPN." This seems to contradict the design 
> description in the introduction, "The design in this document 
> introduces a new extension, called Encrypted Client Hello (ECH), which 
> allows clients to encrypt the entirety of their ClientHello to a 
> supporting server." Am I correct to assume that the text in appendix B 
> is a leftover from the previous version of the draft?
> > Yep! I'd opt to remove this text entirely, but if others want to keep it I suppose we can update the text accordingly.  That's probably the simple option, yes.
> >> I am also not sure on how we could implement the "Optional Record 
> Digests and Trial Decryption" methods described in section 10.3. The 
> syntax description in section 5 specifies the record digest as "opaque 
> record_digest<0..2^16-1>", and defines that field as containing "A 
> cryptographic hash of the ECHConfig structure from which the ECH key 
> was obtained". Would it be correct to implement the "optional record 
> digest" method by just encoding a zero length field?
> > Indeed, that was the intent. Would you prefer a different way? 
> Length 0 is a fine way to mark the absence of an optional component. 
> But I would like a short mention of that either in section 5 or in 
> section 10.3. For example:
> 10.3.  Optional Record Digests and Trial Decryption
>    Optional record digests may be useful in scenarios where clients and
>    client-facing servers do not want to reveal information about the
>    client-facing server in the "encrypted_client_hello" extension.  In
>    such settings, 
> >>                clients prevent server identification by sending
> >> an empty record_digest field in the ClientEncryptedCH, and 
>                   servers must perform trial decrypt upon receipt of an
>    empty record digest, which may exacerbate DoS attacks.  Specifically,
>    an adversary may send malicious ClientHello messages, i.e., those
>    which will not decrypt with any known ECH key, in order to force
>    wasteful decryption.  Servers that support this feature should, for
>    example, implement some form of rate limiting mechanism to limit the
>    damage caused by such attacks.
> Fairly minimal change, but it would clarify the intent and avoid 
> interop problems.

Would you mind creating a PR for this? :-)