Re: [TLS] Binding imported PSKs to KDFs rather than hash functions

"Christopher Wood" <caw@heapingbits.net> Tue, 17 September 2019 14:56 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 BBDB912006A for <tls@ietfa.amsl.com>; Tue, 17 Sep 2019 07:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=D4zJjJ5r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D+Y9UsFj
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 VgVE-0dCtwMD for <tls@ietfa.amsl.com>; Tue, 17 Sep 2019 07:56:48 -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 9BE9F120045 for <tls@ietf.org>; Tue, 17 Sep 2019 07:56:48 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id EF33D6BA for <tls@ietf.org>; Tue, 17 Sep 2019 10:56:47 -0400 (EDT)
Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Tue, 17 Sep 2019 10:56:48 -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=fm2; bh=PFbyc aeub5y8wojuKuroIKutR44HOwge+rBvOlaNUvU=; b=D4zJjJ5r30GpI3sn7spJh mKe862LuT3lAGJQWJDMfQvUNIzo6LXbP12/87dyPYU4UfOrSyk5RBau+ljjmjTy0 jaq9IdXOViXXRffX4URdNCPGN+pBMh/j0ZY83Z/FNRzj4iDuolSpG6gXd/Ki3Hyv DHIrS2DO2l2vCuFs270T0he0h9QO1tsOo9JXeMjHXnBCKSHWSVJhN3kvC+/3hp3+ czJLZIV2nSBG6ynLpygX4+iR3Im+EbKzC1NXDiLTAo35+p5PIzNF32mOhTzbeIoA cs1T0UwE62UCGGfYhr5ENcVUG+avXwivaC8CoXVDqJo7Gyi9NwWB1UvxSyoVlFhf w==
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=fm3; bh=PFbycaeub5y8wojuKuroIKutR44HOwge+rBvOlaNU vU=; b=D+Y9UsFjdetsLkk7C2fENyDZ/gt9OkEznl9igLOtaqESWAwNh0CrOiVen kvYtN1aYPNoRuivdSF46MomgUmQ2a9CPWxE1sP02YnaX0phHPzzH95TfrW3kg6SB yDfBKtOd500Pyad94v4POr1e8rV5Xg0lFnbKJ/Z8iz5rHBdq8Hm16j13XEWqBohq bvIBQcQYtze5RjABmDZVRjhYUsic3L+hb4DrU2zYQqzRMcXLYKDACZwEUCj9cq42 i6BWdUy9DFkgylJ8EWXv6qqJbbTLskv6YZb4zCEb7Ggjl7vqzz/XsPwWNzBhWzZX DGPXC70nJsHBOICzidzN4m6srN6VA==
X-ME-Sender: <xms:L_SAXeYm5jsaVrMnQHHZyJYHUZvfnew0EZ4trR4FvIA49y8UH80rFQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeigdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgif sehhvggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtoh hmpdhivghtfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghp ihhnghgsihhtshdrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:L_SAXTz-GmBU7t2BUaPctI7_JUXJbf90l6JkQG0exBpbxphZjWrmyg> <xmx:L_SAXTiCnGYFK7AXtA-Tvr1frpdCJpSmHUBM6z1FjxP-lNlcRYPEsA> <xmx:L_SAXbIkrHBLqjVKm5DXKIE7LSKJZ27UpHu8FSbY3-0VnD5mRovMZg> <xmx:L_SAXWUy1K5LmBa3WH8aTMFFEyHxZtURcRBgPFcNtssKjo8VLi8rHw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3E5D63C00A1; Tue, 17 Sep 2019 10:56:47 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-238-g170a812-fmstable-20190913v1
Mime-Version: 1.0
Message-Id: <f0aa22d1-0461-47d6-b0c3-c26c664c0d50@www.fastmail.com>
In-Reply-To: <1f5dda7a-576c-4309-b465-7fa93c2d7662@www.fastmail.com>
References: <e484c148-d64b-4538-9145-85e0363b0cc9@www.fastmail.com> <1f5dda7a-576c-4309-b465-7fa93c2d7662@www.fastmail.com>
Date: Tue, 17 Sep 2019 07:56:26 -0700
From: "Christopher Wood" <caw@heapingbits.net>
To: "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/W5V_SYnuRWrl35xyT2ZDlNRL_Ps>
Subject: Re: [TLS] Binding imported PSKs to KDFs rather than hash functions
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, 17 Sep 2019 14:56:52 -0000

Hi Martin,

Thanks for the reply! Please see inline below.

On Mon, Sep 16, 2019, at 6:26 PM, Martin Thomson wrote:
> There are two points here to consider:
> 
> 1. Whether the key that we are feeding into this process is going to be 
> used exclusively for that purpose, or whether it might be used for 
> something else.
> 
> 2. How the key that is output from this process might need diversification.
> 
> What we learned from TLS 1.3 is that HKDF is effectively a completely 
> different KDF when it is used with a different hash function.  And that 
> taking the same key into two different functions was not advisable 
> because there isn't a lot of analysis to support that particular usage 
> pattern.
> 
> In thinking about the first point, we might want to consider whether 
> the KDF that is used in the importer might need to be used in other 
> ways.  

To be clear, you're referring to HKDF and its role in deriving ipsk from epsk, right?

> Personally, when I see the question formulated this way, I am 
> inclined to suggest that this key should be used exclusively for key 
> import.  If that's the decision, that should be made very clear.

I agree. We can state something along the lines of "clients MUST NOT use an external TLS PSK for any other purpose." And also say that external PSKs can only be associated with a single hash function. As you mention above and in your followup message, if this isn't done, then a client may import the same IKM using different hash functions. 

Is this what you had in mind?

> If we decide that we're gaining exclusive access, then the only other 
> consideration I'm aware of on the input side is the binding to the 
> origination of the key, as raised by Jonathan.  That is something we 
> might gain by integrating something into the identity, or by adding a 
> context attribute to the expansion (which might carry a session hash).  
> That concern is not reflected in the proposal here though.
>
> If you have exclusive access to the input keying material, then you can 
> very easily restrict this to HKDF.  If not, then I'd suggest that you 
> need to use the more general form.  But then you also need to ensure 
> that whatever inputs you feed into the KDF can't collide with inputs 
> for the other usages.  That's tricky.

Right. Tricky and likely impossible. There's nothing stopping someone from crafting a PSK with an identity which matches an ImportedIdentity, and then advertising that on the wire.

> Then the question is how we identify the diversification parameters.  
> Right now, we want to diversify outputs based on TLS version and the 
> hash algorithm associated with the cipher suite.  If this is only ever 
> used for TLS, then we have a simple process: we identify the specific 
> type of TLS PRF somehow and bake that into the KDF label.
>
> How we do that is simple mechanics: each version of TLS we care about 
> has a template KDF, which is parameterized by hash function.  As Chris 
> proposes, we could include a TLS version and a hash function 
> identifier.  That seems enough.

I suspect you meant "KDF identifier" here? (The proposal below uses the TLS version and a KDF identifier. It could also use the TLS version and a HashAlgorithm value. Using a KDF identifier is probably more future proof, though.)

> The final question is about multiple PRFs in TLS 1.2.  We never 
> restricted input PSKs in TLS 1.2 to a single KDF, so in theory we could 
> use a single output of this importer function for TLS 1.2.  However, 
> I'm not sure that this is necessary if we allow for the possibility of 
> an importer.  We could use different keys depending on the final 
> selection of cipher suite (and therefore hash function).  I don't see 
> any reason not to fix TLS 1.2 PSK usage at the same time as TLS 1.3.

Sure, it's possible, though I think that's already done? Was there something below or in the draft that made you think otherwise?

Thanks again!
Chris

> 
> On Sun, Sep 15, 2019, at 00:53, Christopher Wood wrote:
> > Hi folks,
> > 
> > Martin reviewed the external PSK draft [1] and filed a couple issues 
> > [2,3] that are worth discussion here. I’d like to call attention to #16 
> > [3] in particular. 
> > 
> > TL;DR: Should we bind the importer to a KDF rather than a hash function?
> > 
> > Currently, the importer draft assumes that an external PSK is 
> > optionally associated with some hash function, and, if not, assumes 
> > SHA256. The importer uses this hash function when deriving the imported 
> > key. In particular, it’s the hash function used for HKDF-Extract and 
> > HKDF-Expand, which runs over the external PSK blob and the constructed 
> > ImportedIdentity to produce a unique, imported PSK. ImportedIdentity is 
> > the structure that contains the external PSK identity, a protocol 
> > label, and target hash function:
> > 
> > ~~~
> > struct {
> >   opaque external_identity<1...2^16-1>;
> >   opaque label<0..2^8-1>;
> >   HashAlgorithm hash;
> > } ImportedIdentity;
> > ~~~
> > 
> > The issue raised pointed out that the (protocol label, hash) tuple 
> > effectively identifies a KDF. (Martin, please correct me if I’m 
> > misinterpreting your comments!) Thus, perhaps it makes sense to replace 
> > this with something simpler, e.g., 
> > 
> > ~~~
> > struct {
> >   opaque external_identity<1...2^16-1>;
> >   uint16 protocol_version;
> >   uint16 kdf_identifier;
> > } ImportedIdentity;
> > ~~~
> > 
> > Where ImportedIdentity.protocol_version is a code point (e.g., 0x0304 
> > for TLS 1.3) and ImportedIdentity.kdf_identifier is a unique 
> > (registry-defined) KDF function (e.g., 0x0001 for HKDF-SHA256). If we 
> > did this, a couple interesting questions arise. 
> > 
> > First, should we keep using HKDF as the importer KDF? Note that the 
> > current ImportedIdentity.hash field is what diversifies imported PSKs 
> > by hash function. The actual key derivation still uses HKDF with the 
> > hash function associated with the external PSK. (SHA-256 is assumed if 
> > none is specified.) If we replaced ImportedIdentity.hash with 
> > ImportedIdentity.kdf_identifier, we would still get this 
> > diversification, since each target KDF is bound to one hash function. 
> > However, should the KDF corresponding to 
> > ImportedIdentity.kdf_identifier be the KDF used by the importer for 
> > derivation? That is, let’s say I have an external PSK "epsk" that's 
> > associated with SHA-512. Moreover, let's assume 
> > ImportedIdentity.kdf_identifier = 0xFEFE, which corresponds to some KDF 
> > called MySpecialKDF. Should the derivation step be this?
> > 
> > ~~~
> > epskx = HKDF-SHA512-Extract(0, epsk)
> > ipskx = HKDFSHA512-Expand-Label(epskx, "derived psk", 
> > Hash(ImportedIdentity), Hash.length)
> > ~~~
> > 
> > Or this?
> > 
> > ~~~
> > epskx = MySpecialKDF-Extract(0, epsk)
> > ipskx = MySpecialKDF-Label(epskx, "derived psk", 
> > MySpecialKDF.Hash(ImportedIdentity), MySpecialKDF.length)
> > ~~~
> > 
> > Or something else entirely?
> > 
> > Second, keys need to be imported for each supported ciphersuite and 
> > corresponding hash function. How would we specify that if we now speak 
> > of importers in terms of a target KDF?
> > 
> > Thanks,
> > Chris (no hat)
> > 
> > [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer
> > [2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15
> > [3] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/16
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>