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

Christopher Wood <caw@heapingbits.net> Tue, 02 June 2020 18:19 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93733A0EB7 for <tls@ietfa.amsl.com>; Tue, 2 Jun 2020 11:19:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=Kebwutzo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d8VDLtAH
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHmLr6TBKxnk for <tls@ietfa.amsl.com>; Tue, 2 Jun 2020 11:19:31 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D88503A0EB3 for <tls@ietf.org>; Tue, 2 Jun 2020 11:19:30 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 241DF5C010C; Tue, 2 Jun 2020 14:19:30 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Tue, 02 Jun 2020 14:19:30 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; 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= messagingengine.com; 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: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6
Mime-Version: 1.0
Message-Id: <4c5b4170-4dbe-43df-b6b4-04a9793da1c2@www.fastmail.com>
In-Reply-To: <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net>
References: <159104051676.18465.12498199656412028384@ietfa.amsl.com> <af75a707-3b6c-a1af-14c4-6e766cb4e572@huitema.net> <c7a41e95-8b21-4620-806e-db144eac2fa3@www.fastmail.com> <4385bb35-710b-311d-2b7c-fad0eb72c5d3@huitema.net>
Date: Tue, 02 Jun 2020 11:18:35 -0700
From: Christopher Wood <caw@heapingbits.net>
To: Christian Huitema <huitema@huitema.net>, "TLS@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/XCjFN1u7RHi7l1pUBr_3P2L4wZo>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-esni-07.txt
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: 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? :-)

Thanks,
Chris