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

"Christopher Wood" <> Wed, 18 September 2019 15:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 744B41208BD for <>; Wed, 18 Sep 2019 08:41:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=P6mnASLh; dkim=pass (2048-bit key) header.b=1aD1fey3
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tCmWs2fhfc5w for <>; Wed, 18 Sep 2019 08:41:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 579C812086A for <>; Wed, 18 Sep 2019 08:41:45 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 71A6120F51 for <>; Wed, 18 Sep 2019 11:41:44 -0400 (EDT)
Received: from imap4 ([]) by compute6.internal (MEProxy); Wed, 18 Sep 2019 11:41:44 -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; s=fm2; bh=BAI8RCBQn81xlgpznnpw8+WV61BXVLi pLBEq0PA7LAY=; b=P6mnASLh8VRL59U5OwyQS4F23pptu/Kw0hJ8mSVMBQ+IgGR AhEwg/oMkb1zxntw1ML2tDc072VkuuTcCD+EGZyMWPsgH4CiICY09See0IXYpQkz ctMA7dIgzJLFN3WiLaKwuuVYJZsS5iBF2LpS81PYdSUAB+ObJpYk6j/tXaEQ9UTG uhj2ZP6V/+B/ecGRQv6qaPHyEPDH5jjtw3f8woWthfRApGc7uWZ17rZ7MdtAbnVw zkpc2xzg/E8b4atyJi7X0tVv7+oVI466h2cqADTWwh9FXtw68deXD9bWRUeUSYEx GqDWcUfx3QRMj1kqDGOQV6XZ8kBKneQFaFXa4Pg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=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=BAI8RC BQn81xlgpznnpw8+WV61BXVLipLBEq0PA7LAY=; b=1aD1fey36/6pPazOShXhIB Q+PAU0oSKoh6rkuCXFzfDzURuLcvVSeo+6Umf+wMvm6++hWFe2iM4+YKDFf4mAwb M9eSZdjhFcRLjAP/nrOSGZrAeA2WM0xLjATOdgPIXX+LO2Vqh51wze7YgYkKQC4J nqYJ7kBvZkp3+ohYxTJfQUAJ+cSvuvIRenRYzFUIuhMgH5HYflb60D2t4Y6UIREr 3EsjY4uPXrEb102H+m2ATdkJVtLwmT0/UYW1by6361FR930rfSn+L9Mx98Do9dua K8a5PbcHB1hKCe1/kX7umrdPaGxdwTVFNxyt9fbvDVcw1Ph48Ont94IHrNawMd2A ==
X-ME-Sender: <xms:OFCCXXYdguul6oK_LD4YrJxVdld1aZK_eIj7S2PEf6_YoiTNrX1K4w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudekgdeltdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdevhhhrihhsthhophhhvghrucghohhougdfuceotggrfies hhgvrghpihhnghgsihhtshdrnhgvtheqnecuffhomhgrihhnpehgihhthhhusgdrtghomh enucfrrghrrghmpehmrghilhhfrhhomheptggrfieshhgvrghpihhnghgsihhtshdrnhgv thenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:OFCCXQpmPm1nzk5u8ciTsCLge7EOGmc1npctZ5k0Pyq31i1AVJfTAA> <xmx:OFCCXTQRuOnoIt9FxDaqF4Jtsgja__nxP7MuOYzt-tr-TuRYY589Rw> <xmx:OFCCXQ_5vsUagOAPjJ0tY8mlD2gSbZ0GAmCHW2GLrlB2tWbwGndOng> <xmx:OFCCXTTqLESSQBR-aNfMgbDax0Z8TcNKSCGQyguRT0vSQXGc0PZFYA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 22AAE3C00A2; Wed, 18 Sep 2019 11:41:44 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-238-g170a812-fmstable-20190913v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <> <>
Date: Wed, 18 Sep 2019 08:41:23 -0700
From: Christopher Wood <>
To: "" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Binding imported PSKs to KDFs rather than hash functions
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: Wed, 18 Sep 2019 15:41:48 -0000

On Tue, Sep 17, 2019, at 7:03 PM, Martin Thomson wrote:
> On Wed, Sep 18, 2019, at 00:56, Christopher Wood wrote:
> > > 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?
> Right.  Though I see epsk -> ipskx in the draft.  Not sure why that has an 'x'.

It was an editorial thing meant to help disambiguate keys. We can probably clean this up.

> > 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?
> Yeah.  `epsk` can only be used for importation into TLS using this 
> mechanism and only with a single hash function.

Great! I'll draft a PR with this restriction that builds on

> > 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.
> We can't stop all the bad ideas :)
> One thing that bothers me a little: how did you plan to identify these? 
>  I imagine that you would only need to identify the epsk in the TLS 
> handshake.  You don't plan to use some derived means of identification, 
> do you?  The doc is light on details here and could probably use some 
> text on this point.

Assuming you're referencing imported keys by "these", the identity sent on the wire is the constructed ImportedIdentity structure. I'll try to make that more clear.

> > 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.)
> Yeah, a KDF identifier is more robust, for sure.  It is probably not 
> coincidence that version+hash is enough for now, but we can be a tad 
> more general in the interests of making this more robust.

Agreed. A downside here is that we're then forced into a registry for the KDFs. I'd prefer referencing something like HPKE for that. 

> > Sure, it's possible, though I think that's already done? Was there 
> > something below or in the draft that made you think otherwise?
> Probably just the discussions on GitHub and the lack of discrete 
> identifiers for the TLS 1.2 KDFs in the IANA section.  If we're 
> identifying KDFs, then we should identify TLS 1.2 KDF separately from 
> the TLS 1.3 ones.

Ah, so, I think this is where the miscommunication is happening! The target KDFs I've been envisioning are not protocol specific. So, we wouldn't use the TLS 1.2 PRF. We'd just use the identifier for HKDF-SHA256, or whatever. (Since the hash algorithm is what's important, and is effectively what identifies the TLS 1.2 PRF, I don't see the need to specifically reference the 1.2 PRF. It seems we can just target a hash-specific KDF.) 

In an attempt to clarify my mental model, here's a proposal of I mean. First, define ImportedIdentity as follows:

   struct {
       opaque external_identity<1...2^16-1>;
       opaque context<0..2^16-1>;
       uint16 protocol;
       uint16 kdf;
   } ImportedIdentity;

And then define the KDF registry (here or elsewhere) as:

| KDF Name.        | KDF ID |
| HKDF-SHA256 |  0x0001  |
| HKDF-SHA384 |  0x0002  |
| ...                          |  ...             | // maybe add one for the MD5+SHA1 PRF

Then, when importing one PSK for TLS 1.2 and 1.3, targeting SHA256, we'd import two keys: one with ImportedIdentity.protocol = 0x0303 and ImportedIdentity.kdf = 0x0001, and another with the same KDF identifier but ImportedIdentity.protocol = 0x0304. 

If I'm still missing your point (or if the preceding proposal is simply wrong!), can you update the text above or propose new text to clarify?

Thanks again for the continued discussion.