Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites

Martin Thomson <mt@lowentropy.net> Mon, 17 August 2020 22:30 UTC

Return-Path: <mt@lowentropy.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 D79223A12E0 for <tls@ietfa.amsl.com>; Mon, 17 Aug 2020 15:30:40 -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=lowentropy.net header.b=eUNJfS7/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Q+Xt7g8x
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 AinlU62u6sKQ for <tls@ietfa.amsl.com>; Mon, 17 Aug 2020 15:30:39 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1D53A12D9 for <tls@ietf.org>; Mon, 17 Aug 2020 15:30:39 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id C2892AA1; Mon, 17 Aug 2020 18:30:38 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Mon, 17 Aug 2020 18:30:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=f+FDfKwguuC5uZH4qXWwTLLJUILP EpkesWpJNr5Vn00=; b=eUNJfS7/nTYhtPjbLsq4dRTx0fMPwr+7gXH9eP9SXyEt sUZSNZinB7TfdvSFgcopXbdfneUJxnE/pmdnP62KDYAccO8cVBovIFcnulTdOoG5 aCzhrWVLZvHgaQ7shiED13gDHCDTNxz17tFIcBoJkPctX3WljuVfX8P2Olxa79GM QtlPfcgcF4gmR2ozzdMUDXKJmiXQDMZrKi5FHFPw14ZGgIylLIWJCJD8D3jcbu6L ydm2fit6/IrrPY1YADlN/PtKoLzcJdFtdCjZL4w9ojzCUCy/irJ1wASCC2MyApJU Aa21vu5/HUb3iIRP6jUw1Wbc8FvAyfu5m6bbPb9bsA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm3; bh=f+FDfK wguuC5uZH4qXWwTLLJUILPEpkesWpJNr5Vn00=; b=Q+Xt7g8x0CMxIkDaaLxpJI Q8u/PetmZ4Nz/j7HEoSeWwJ+WFsA62r3ESqduETDRECMjb+lktwVZaesWg4fbFIf CB9Fu1GdUwAw5evI9/f18OABjcHNIryzmtgKvPCR/EGuvWyiUX1+XAWWVcEMcgPr eayl93Zp0YsxygFs05uiCs/kc6eb3Rt04BnQHt8R5YzhfGyJoOCDRut2f+uRnEKg vIlmn5YWWUFJJVOcKjqLNY7pN1uDoaCBK/WLWo5nITwJVbI9neVWAxgsikkz3HpK VebJrZicTTlaUvvJNjIgNhDaJmwtZjjXp+Ld73cp/YEhFitRIeYwil4dRE/ONP5A ==
X-ME-Sender: <xms:DgU7X65WsWVfoQEUXDFHQMpC_CyGuS-7K9O0gBqXvcdXykjm-1G0pw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedruddthedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecugg ftrfgrthhtvghrnhepveeffffgtdehgfefkeefjeehtdekheegieehfedvgfeiieehvdek jedvveevleeinecuffhomhgrihhnpehirggtrhdrohhrghenucevlhhushhtvghrufhiii gvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhn vght
X-ME-Proxy: <xmx:DgU7Xz5YwLS7n5i4nIYMIgumzucBOznOx_nERTjrKKb_nUmjMNz75w> <xmx:DgU7X5eetdkhUe1vO_lClb9F6ZhZ8q-ZRca1ha3AiaX-JwCf-ZxlwQ> <xmx:DgU7X3Kc50h10gRBYyxs6g4MkMnXdKCzIVrXboUW4HmeDzmOCAWWHg> <xmx:DgU7XzWpKGbsUBFStyWDOCxRGHujn3FhuPIdZay9M6FriQq6imUNAw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 30DA9E00B3; Mon, 17 Aug 2020 18:30:38 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-192-gd9d7a78-fm-20200816.001-gd9d7a786
Mime-Version: 1.0
Message-Id: <dae86080-2818-4ea8-8c2d-ae8cf55ab149@www.fastmail.com>
In-Reply-To: <CAG2Zi22BdP_EYGrCiDMqKrkQN4ZwE-igBjQypMbUJrSiaXER=A@mail.gmail.com>
References: <ee8c4bb1-554a-4f45-a1d5-17e49b320562@www.fastmail.com> <170e077f-2ad1-4794-9227-b7e9fcf74b0c@www.fastmail.com> <CAG2Zi22BdP_EYGrCiDMqKrkQN4ZwE-igBjQypMbUJrSiaXER=A@mail.gmail.com>
Date: Tue, 18 Aug 2020 08:30:18 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: "Christopher Patton" <cpatton@cloudflare.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iEl7GGc42Oi8flu9UJiBbd_vJ2I>
Subject: Re: [TLS] Constraining ECH to HKDF-based HPKE ciphersuites
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: Mon, 17 Aug 2020 22:30:41 -0000


On Tue, Aug 18, 2020, at 07:55, Christopher Patton wrote:
> Hi Martin, 
>  
> > Or maybe just running the HPKE KDF with a fixed input.
> Do you mean something like this? Let `config_digest = KDF.extract("some 
> salt", "some label", config)`, where `config` is the ECH configuration?

Sure.  I would probably use all of HKDF though, see below.

> > Unless I've missed something critical, you don't need any sort of 
> preimage resistance for this, it's only for identification purposes.
> The manner in which `config_digest` is computed could be significant to 
> "don't stick out", depending on how you define this property. For 
> example, one requirement for the hash function might be that it is 
> one-way.

So the current system has the property that anyone in possession of the original config can confirm that this is the config in use.  And we have assumed that the config does not contain secrets.

Being unable to recover one input seems to be a KDF property.  We could feed config to that input (for the full HKDF, that would be IKM, I think).  See definition 7 in https://eprint.iacr.org/2010/264.pdf, which supports the theory that a KDF is a PRF with respect to at least one input (\sigma in the same).

I think that the only case where being able to compute the inverse becomes interesting is if the config contains a secret.  Let's say that you use a config that includes a PSK.  The answer there could just be "don't do that then".  Or we could work something out (for example, a nonce of sufficient length might ensure that a secret could not be reconstructed even if everything else were predictable).