Re: [TLS] Binder key labels for imported PSKs

"Martin Thomson" <> Thu, 05 September 2019 23:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23D71120B3E for <>; Thu, 5 Sep 2019 16:46:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
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: (amavisd-new); dkim=pass (2048-bit key) header.b=S65syv+j; dkim=pass (2048-bit key) header.b=eomviMzd
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b4BwsZoG7iu0 for <>; Thu, 5 Sep 2019 16:46:32 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B93CA120B34 for <>; Thu, 5 Sep 2019 16:46:32 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 950E121A97; Thu, 5 Sep 2019 19:46:29 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Thu, 05 Sep 2019 19:46:29 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm3; bh=Qi5ot3jKmMGcUNI/pB4TxlpmXbuc ja57C4GX+svxVRQ=; b=S65syv+juyrrkuukXem8v29k1cNeGdCskI6BYTJjcsjb 33cl5jFGS99BdN1qcuxRM1Uu5Ed6tEz2sH6WNg/tkB2mnlybB1i2UXKQUJaQoLfY +9cfKMCVDgkI/WZqLqaEAGMvzNgEp2Vy4SZJdUYnsjf8NMtlxx9eydo/2C3pvEMV 32rSKdPTxzK4nbMq/wTJcvkM0JPJzN/yC3v47rQPlIbIzKOB3JGX0K5WAFX9bn9r dY2GOneX5Tea0r9pUPTM5LSqE6L8DEOFmrHZpD7TJalBeLoKaGGTDMYjWZuyd08/ NzsaYC0Uck7COLgFGc/vEFvIGeACUwH1l2ZYZzusng==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; 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=Qi5ot3 jKmMGcUNI/pB4TxlpmXbucja57C4GX+svxVRQ=; b=eomviMzdWBFKNYKQM7cwsW 7lHhd02h2I8cFkNm5CHvoANGY9dh30PfCB/2uMpYyJMdS6gKzgQ3bZNpajq5CFSv s4LE3svOdpDxwfJ7UUwVdc3RU08kUIROgZt6C4eGbOOaN8DlJwjqqQy6h/xC1g8X 1PXJ/hjtNpGqgigwQAr7Sh83jGy8to5rrkLZAWLuPKxPmyCkpJdC+rnJU07gMMoq D/Dj9wmp5jCpyeJrouw2WXLkIVO/N4eUtPDdJaFnr/XhCs39hq0Hsf/VxvTF/GXm 1CfSjp7oVtL6wOWPd19WiR493OHUiU/t93sP2YgXRRPRheMpLEv/W7kavDcfTu6w ==
X-ME-Sender: <xms:VZ5xXdl7KJ1qmvLdTIhqB5VpSQzEvhK4JAfJs5n8MtGh57YYJ8uHAQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejkedgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecurfgrrhgrmhepmhgr ihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuih iivgeptd
X-ME-Proxy: <xmx:VZ5xXUZYn2liLkc7iXynpVkxcPXDFZoFA8jfnbBK0ludgL74h4xjdQ> <xmx:VZ5xXToWqgQNBzKNAB_flUY6qFWHnuUJbYqxCrA1N0W82vUUYyxZnw> <xmx:VZ5xXSiGLJiWCRpTr1GysLLo9MSvgKUfWUZeCmSOfUuwQMaiVOhKow> <xmx:VZ5xXeG1w--O9AB8ZzNSl_fpttWqy-u3raloVQA3jbN9-FlXQXq2tA>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4631DE00A3; Thu, 5 Sep 2019 19:46:29 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-188-g385deb1-fmstable-20190905v2
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <> <> <>
Date: Fri, 06 Sep 2019 09:46:08 +1000
From: Martin Thomson <>
To: Jonathan Hoyland <>
Cc: "<>" <>
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Binder key labels for imported PSKs
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: Thu, 05 Sep 2019 23:46:39 -0000

That's a much better answer than I was looking for :)

That makes sense.  The gap between theory and practice here is still something that is worth spending some time on, but I can see how that is something that we might want to keep out of this document.  The goal here is simple: take a PSK that is bound to one KDF and apply a transform that will allow it to be used with TLS ... in a way where the choice of cipher suite is not constrained by the properties of that PSK.

Understanding your broader goals better leads me to conclude that issue #15 ( is more important to resolve.

On Thu, Sep 5, 2019, at 20:56, Jonathan Hoyland wrote:
> Hi Martin,
> So I agree that on the micro-scale there is limited practical value to 
> be gained from adding this binding.
> The theoretical benefits, which mean that the client and server agree 
> that PSK Importers are being used are nice, but on their own might not 
> justify a high-effort change. 
> However, at the macro-scale I think this is an interesting and useful 
> addition.
> In particular I think we can use this change to address what I see as a 
> short-coming of TLS 1.3 in general. 
> Being able to use TLS as a building block for other protocols is really 
> powerful and useful, but the current mechanisms are unnecessarily 
> restrictive. 
> I have spent a lot of time thinking about exporter keys, and the way 
> they let us combine other protocols with TLS. 
> TLS has really nice, strong, properties, and being able to leverage 
> them in other protocols makes designing complex protocols much easier, 
> especially from a formal analysis perspective. 
> One limitation of exporter keys, however, is that you need to use TLS 
> as your first/base protocol. 
> Whilst you can use exporter keys to securely run a protocol over the 
> top of TLS and get the guarantees of both*, you cannot run TLS inside 
> another protocol and easily get the security guarantees of both*. 
> I think that this restriction is unnecessary. 
> My overarching goal is to make it possible to securely put protocol 
> building blocks before TLS. 
> The way you would achieve this is by allowing such blocks to be chained 
> together and then bound into the TLS handshake.
> Ideally, all protocols that wish to use TLS in this way would use this 
> key-schedule extension, allowing for complex state to be built up and 
> composed into the TLS handshake.
> PSK Importers are, to my mind, a good place to start. 
> Agreeing on a change of hash function can be viewed as a very small, 
> very simple protocol. 
> The necessary modifications are small, and the benefits, whilst 
> incremental, are clear. 
> The modification to the key schedule means that both parties can be 
> sure that the other agrees that they are using PSK Importers and 
> further, that they agree on the original hash function and the new hash 
> function.
> Other protocols can then also make use of this extension to the key 
> schedule to achieve similar aims. 
> The idea would be that any protocol that uses this label implies that 
> it is providing a context field (which may or may not be empty). 
> These protocols can then be chained together in an agreed order, and 
> the agreement properties of TLS can be used to verify that both parties 
> agree on the transcripts of the previous protocols. 
> Making this change allows us to leverage this power in future to make 
> any number of more useful protocols. 
> However, without a key schedule change, there is no way for a Client 
> and Server to be sure that their peer is actually using TLS as a 
> building block, which kneecaps any ability to compose it with other 
> protocols. 
> In this case it means that a Client cannot be sure that it agrees with 
> the Server on the status of their relationship, and vice versa.
> So to directly answer your question, the value of the distinction in 
> this case is incremental, but opens the door for other 
> extensions/protocols to leverage it to provide arbitrarily complex 
> guarantees**. 
> There may be a case for working on a backwards compatible way of doing 
> this, where a client offers PSK Importers multiple times with binders 
> computed both ways, but I don't think that it's necessarily a good 
> idea. 
> Regards,
> Jonathan
> * The guarantees it is possible to get from this key-schedule change 
> are a little bit nuanced, because a PSK handshake doesn't rely on a 
> long-term asymmetric key, but that's a discussion for another time. 
> ** Modulo limitations on outward compound authentication. 
> On Wed, 4 Sep 2019 at 02:46, Martin Thomson <> wrote:
> > I want to push on this a little harder. Not because I don't think that more formal protections in the line of key separation are bad (they are great), but more to dig into the real reasons driving this change. The justification I've gotten thus far is somewhat superficial, and I want to see if there is something fundamental that we can point at.
> > 
> >  When we built the ext/res distinction, there was a clear problem expressed. We had the potential for both to be used by the same servers at the same time (though not for the same connection) and distinguishing between them was important. It wasn't so much that agreement about provenance of keys was important, but more what it meant for that provenance to be confused. A resumption key implies a number of things about the new session that extend from the previous session, whereas a straight external key does not imply the same. If a client and server were to disagree on these properties, one might assume properties of the resulting session that the other did not and we would be in a bad place.
> > 
> >  It's true that servers are in complete control over how keys are identified, and so this could always be addressed by the server by ensuring that key identifiers clearly distinguish between the two types. However, that protection would be informal and ad hoc. We wouldn't guarantee that separation by any mechanism. By applying different labels to the binder key we produce, disagreement results in interoperability failure (both client and server could be wrong, but at least they then agree, which is the property we really need).
> > 
> >  As an aside, we could have used explicit labels in the protocol, but we decided that an implicit one was better. For the record, I still think that's a good design paradigm to apply.
> > 
> >  The concern with the ext/res distinction doesn't seem to apply equally here. For simplicity, I think that we should consider this a path into the "ext" bucket, so that we have an resumption/other analysis holding (as above), and an external/imported analysis to perform in order to arrive at the "other" category. The question then becomes whether to fully distinguish imported PSKs from "regular" external PSKs.
> > 
> >  I think that the context of use is important to consider. The imported PSK will enter the key schedule (as shown below) after having been through a derivation process that includes additional information: most importantly, the protocol version and the hash function that the resulting PSK will be bound to. That produces something that could coexist with other uniformly random PSKs of sufficient entropy (i.e., it wouldn't collide with "external" PSKs with non-negligible probability). Because neither imported nor external PSKs come with any different presumption about the session that is ultimately produced, the same rationale for ext/res doesn't apply, and I'm struggling to find any stronger justification.
> > 
> >  The cost of adding more separation is forced changes to code. With the design prior to this, the importer function was loosely coupled to the TLS stack. It would be possible to manufacture as many "external" PSKs as needed from an root "imported" PSK. The resulting outputs could be fed to endpoints that haven't been updated to support this new importer stuff. That's obviously less clean than having native support for this, because the amount and complexity of key provisioning is higher, but it could have worked. This now requires code changes to deploy.
> > 
> >  So I'm not seeing strong cause here.
> > 
> >  To me, the relevant question is: Do client and server need to agree that this is an imported PSK as distinct from another form of external PSK? Or, what is the value of this distinction?
> > 
> >  On Tue, Sep 3, 2019, at 09:29, Christopher Wood wrote:
> >  > Hi folks,
> >  > 
> >  > 
> >  > Per Jonathan Hoyland's recommendation, we're considering adding a new 
> >  > binder_key label ("imp binder") for imported PSKs. Specifically, this 
> >  > changes the key schedule from this:
> >  > 
> >  > ~~~
> >  > 0
> >  > |
> >  > v
> >  > PSK -> HKDF-Extract = Early Secret
> >  > |
> >  > +-----> Derive-Secret(., "ext binder" | "res binder", "")
> >  > | = binder_key
> >  > ~~~
> >  > 
> >  > to this:
> >  > 
> >  > ~~~
> >  > 0
> >  > |
> >  > v
> >  > PSK -> HKDF-Extract = Early Secret
> >  > |
> >  > +-----> Derive-Secret(., "ext binder"
> >  > | | "res binder"
> >  > | | "imp binder", "")
> >  > | = binder_key
> >  > ~~~
> >  > 
> >  > Details can be found in the PR [1]. 
> >  > 
> >  > This does not seem to affect the interoperability story (imported keys 
> >  > are further differentiated from non-imported keys). However, it's non 
> >  > trivial, so we'd like feedback from the group before merging the change.
> >  > 
> >  > Thanks!
> >  > Chris (no hat)
> >  > 
> >  > [1]
> >  > 
> >  > _______________________________________________
> >  > TLS mailing list
> >  >
> >  >
> >  >
> > 
> >  _______________________________________________
> >  TLS mailing list
> >
> >