Re: [TLS] Binder key labels for imported PSKs

"Martin Thomson" <> Wed, 04 September 2019 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BAA4612008D for <>; Tue, 3 Sep 2019 18:45:57 -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=ttVoCFMb; dkim=pass (2048-bit key) header.b=pxzNYuFX
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9nbXCPm_VQiT for <>; Tue, 3 Sep 2019 18:45:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5D9A412007C for <>; Tue, 3 Sep 2019 18:45:55 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 91F6422305 for <>; Tue, 3 Sep 2019 21:45:54 -0400 (EDT)
Received: from imap2 ([]) by compute1.internal (MEProxy); Tue, 03 Sep 2019 21:45:54 -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=dfgqdw434U6Ni0ZxFrT6KKC81yN1yLZ mduSEQWtjuZo=; b=ttVoCFMbcT2XhU9l5DPhfh40gTbX1mBN0BtYxVkc0Y9xwty Oh3G+hvR1V6yGJ60F9pE6t/f3BKmMlXkmdsdAWxpjjENWBFMDLTKkk3Os61cc4a1 U79HXfkNVeOu5Y7DxltmeQpWLzTDqChRK1bBziwLhx6N32Pg0A2tf4VjFPV7LZFe cf5GLAQ+4Foj8fzgOoMxKO2+8FVrmUjn8sv304NbaYvBK5hNi6jwDbayxZ+0cevR oQ+1Ex/QaQkhjt2L+Aeyn5mOE5Si6IaUwGcqvz8mGyWRHymWGas6CuF6qFYoo0xl OIjdAp8yq/c5I0o7BrAtm/GqJeONQ93zveSMbmg==
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=dfgqdw 434U6Ni0ZxFrT6KKC81yN1yLZmduSEQWtjuZo=; b=pxzNYuFXLUEcmkk+1Xm/OV Eqpz1tH9fa4UVUnr7yCT059VVLaFOZqx1/rn3VaRjex892wPCRDlO5HkajIgqlZI aXMunPzRETr/cGUwo2/Yx+P0jcqCk4B3UBgUNjpmlai6tnkA5Sy9wM3GAGyOw6/G bJmvo83M5TRldZGIjMUUSgp1yPTiP+A5Dd6LqY+mUhqM5w6TfBMkQU0/ALLqNI+W zQ1QN/spimVWya0SBMtqDlUVl7uKUIPwcevI4P4T5wJ9a0GCQwZElNGIO8ykhiO6 xNPm6xT6s/rmacsr/5FsG3JRi9gneB/gWRyDMjLeZz6/4Aznhi0qnjMmnKy2kBQg ==
X-ME-Sender: <xms:UhdvXV5PCH_i1jodQSYckG8_VQu7E2BDAAfthVoA3irmlUbwTCRp3g>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudejgedggeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhivg htfhdrohhrghenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhp hidrnhgvthenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:UhdvXbFTuRhXn8LydzMybGdOFYmeOBmi8Go8Eks1rGZYF5-wSS31eg> <xmx:UhdvXUhU6o8w_cMGl49ho65Wd6Ac4WKhEP5zbX2_MVZP35n6WRxaKg> <xmx:UhdvXUT5rvX2_MeTUvAp37AZqIaVL6ELRy3Zf9W6srZrmCxZZUf0pw> <xmx:UhdvXbdpaAjudUV9Pika4oTT4hsjtxIVDrr8WGKGc_lT2t2snlGR8Q>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25EABE00A3; Tue, 3 Sep 2019 21:45:54 -0400 (EDT)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-154-gfa7592a-fmstable-20190829v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Wed, 04 Sep 2019 11:45:34 +1000
From: Martin Thomson <>
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: Wed, 04 Sep 2019 01:45:58 -0000

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