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

"Martin Thomson" <> Wed, 18 September 2019 02:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BB50D12012E for <>; Tue, 17 Sep 2019 19:03:48 -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=VlhwM2IL; dkim=pass (2048-bit key) header.b=xAQRU+XJ
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 82SiMnf4Xr_8 for <>; Tue, 17 Sep 2019 19:03:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDF1812011E for <>; Tue, 17 Sep 2019 19:03:46 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 367B4502 for <>; Tue, 17 Sep 2019 22:03:46 -0400 (EDT)
Received: from imap7 ([]) by compute1.internal (MEProxy); Tue, 17 Sep 2019 22:03:46 -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=fm3; bh=w27xAg/0XXivdIb9nHqLSULCMccE8i5 09j56cwIm9fo=; b=VlhwM2ILxD0lZBP6M2CuSnqqdFa9wnSeAOXxoDDN0NpaFjZ igVNH23L0WlQNLupP3k+lb05GLgfbTDaDlvAuagzKE9PbGcUyCAbdihKTv18I+mT Y2o9zfYPuT6HBtpQZj5xR/sHR004p5cP3jsQWv3bJPn5Fp/O9ZvZivoTMlESul0J hJzAMpomOwkxcVgFXSOxSXL0lJMkyK2ZzFVb5gtzoqXBZDs/nwlgjHmuNbfsopOe xFQQRo/9GgQaYP0jocxaf0HyHlKEUnJQZQKprOGL0hv1Rs+QwzCNrZp+4P0hbWC7 bo75JautUJp7UY1ZoAgaZ4DRXLEB+7zTg02yOzg==
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=w27xAg /0XXivdIb9nHqLSULCMccE8i509j56cwIm9fo=; b=xAQRU+XJ0VnDnbhUQOYpcq Cq2cPfOryqDCyAnlrYaJ1Jl1mUokJPRMgDQDZyqSE6Wt66jVU8BNrkpRMi8XJgFT 4d4pV8/2iso08viZE7jDuX4pR4Fvsigq8qZWunpVqbdIzOQMgNzFYUnVVq/gvJNE Re+M9CNJLsy7M6vK5nTgka3jZHc4Et0x46YwOZDa1FjKyK9M91eX7GLjiZoq63fO cmEzXyuxTUH5e3T55n9uFrezapWAAKqCF9vyH8dbg5OWUtC1en/JoL6Is7pxaCPX JrLbNRaQNZWtmtkxgr1u9iRk5nls4f48O5FO8ulh3rNGt5JqiKMJB91ivXdGRGNg ==
X-ME-Sender: <xms:gZCBXarMFa3_xotY3xRIhoS3C38ZkPQ3csER6nSamS-7jjWGWs7nVg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudejgdehhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofi gvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:gZCBXUD_H3_W2CsAaHLs1BL70bkaGe3g5rtjhx6C3dfEz9adDIMBtw> <xmx:gZCBXYk0pNtUFbhdWO1_5-nI2qKQX23Z0lrPvC7YPXztWPRy-wqYsg> <xmx:gZCBXRq81Lu8Na_v6SoimiPGkWlbakuxGDGNzUuT5OPJsqkNYWaWeg> <xmx:gZCBXXmeugsyuO7t9-bokENN5R5PEo_YQjGrYST-7rpXi56qVUfORA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 727A11C0001; Tue, 17 Sep 2019 22:03:45 -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 12:03:26 +1000
From: Martin Thomson <>
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 02:03:49 -0000

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'.

> 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.

> 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.
> 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.
> 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.