Re: [TLS] Binder key labels for imported PSKs

Sean Turner <> Wed, 06 November 2019 01:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A67E5120041 for <>; Tue, 5 Nov 2019 17:51:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id saYM7R2_xcxP for <>; Tue, 5 Nov 2019 17:51:43 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21C3F120154 for <>; Tue, 5 Nov 2019 17:51:43 -0800 (PST)
Received: by with SMTP id d13so23203080qko.3 for <>; Tue, 05 Nov 2019 17:51:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=mJztGmtBCZT98HD4hYbgW6G3FqlgYFLTZgez9T3qKoI=; b=Ij+O+8cIsX8tLN2xsrRhCHT6RbW1zKJsBIZiYv/YT/HpKbToJ0sjML/VsC4Vlek55J q95Ne0OqPTp3xMI04kShcERa+icNxmmzRDmNciA65y4gZd4mxwWOc3oXyOKTqCFdHZ2n wFuA90OOEQ1XdIopZu4RWKgLcnQor3BI2NoBs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=mJztGmtBCZT98HD4hYbgW6G3FqlgYFLTZgez9T3qKoI=; b=kVXAnayyHWT6Uxy6S1FofshG600MTkjZGn0U4BdBSBPMpPeyT6KntAiyIz+YYEiP7S xrVX6kH0gmwatlUJ1uSyeKoEVRO87xkQ8nHAremePgvGVS64PGd6uEuPWIxEBzosTDAM xwjmPTH3z09ZDuROk1Ld4IAXEcbEo7ArkPoSXzym2JjRviHk03fDc7XXXKAfPAePvrEK vkMJE5z6qUwTJFYr9oEF2MPyP5dqdXZDYNIsAhq6uNqwLfqTN/UAczPy2ISmSMgimpHw Bo5yQmMmGsdhX++GpHhUeOATWaPYQrKxuO5cESjic0Qoz+/KGoxwKzfym6q/mArQO1nO 4EKA==
X-Gm-Message-State: APjAAAV4SM6leT7obZe0XvmPMvk4f6SQZpxEw/0u+F86D52d9J7ligT9 V/1ZpYiwqr8IH7vpGdxxVkvjY8Sceiw=
X-Google-Smtp-Source: APXvYqx/0gIIdEAfEzoEpYoBxDE1QQgxh8z6PV+B4O8Q5FA+gFgGTRrPIELOYhBP+jNqHvKfgX5pbg==
X-Received: by 2002:a37:9782:: with SMTP id z124mr22385qkd.62.1573005101524; Tue, 05 Nov 2019 17:51:41 -0800 (PST)
Received: from sn3rd.lan ([]) by with ESMTPSA id l14sm9165838qkj.61.2019. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Nov 2019 17:51:40 -0800 (PST)
From: Sean Turner <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 05 Nov 2019 20:51:40 -0500
References: <> <> <> <> <>
To: TLS List <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3445.104.11)
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: Wed, 06 Nov 2019 01:51:46 -0000

We are obviously going to be discussing this outstanding PRs in Singapore, but I am kind of hoping that we can knock this out before then.  Do people agree that we want to prevent PSK Importers from being confused with standard OOB PSKs and that we should do this by changing the label used in the computation of the PSK binder key?


> On Oct 11, 2019, at 12:48, Christopher Wood <> wrote:
> Hi folks,
> Since #15 has been resolved, we'd like to revisit the proposed key schedule label modification here:
> Please have a look and comment!
> Thanks,
> Chris
> On Thu, Sep 5, 2019, at 4:46 PM, Martin Thomson wrote:
>> 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
>> _______________________________________________
>> TLS mailing list
> _______________________________________________
> TLS mailing list