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

"Christopher Wood" <caw@heapingbits.net> Sat, 14 September 2019 14:53 UTC

Return-Path: <caw@heapingbits.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DDA0512004C for <tls@ietfa.amsl.com>; Sat, 14 Sep 2019 07:53:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=lFEBttgt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ulWsGmyQ
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id pLA5UfbUWSsC for <tls@ietfa.amsl.com>; Sat, 14 Sep 2019 07:53:41 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0599120043 for <TLS@ietf.org>; Sat, 14 Sep 2019 07:53:41 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id C111F20F51 for <TLS@ietf.org>; Sat, 14 Sep 2019 10:53:40 -0400 (EDT)
Received: from imap4 ([]) by compute6.internal (MEProxy); Sat, 14 Sep 2019 10:53:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:date:from:to:subject:content-type :content-transfer-encoding; s=fm2; bh=kBtod5HJulqv4Rw0ZW6LpjavEv GlfOtfRLNf/jX+ZTs=; b=lFEBttgtVCFVtkvqqRsUTJy7sYvFfWg71B8o9Ij+cD 8ds0vHh3bItdJdetjMOIq7XZzyk6YwTNEm3cRXVwmTRFQ019UGTvJER/N2FftAay OgLlJqERlPBPBjhGuOAkFbSMLIuOlhQ/nqkWWiypWUpejQuBYNvsmHAYisljxARJ OO7tpsSlbzot4nu9UA6W4y8vdRWXcEircs+37ho9gqf+vGmwcetLEiJuiKLUR2YW 6xpgkbB9CVpWBSigerUAiU25Jniu3+ggGbOTk2jTaCnu+2En2r6MaSKZRzkJfFMG joZKMb/KUASZQmuCJ/n8wn2cgt76XvJ9mPLwNYHg5ktg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=kBtod5 HJulqv4Rw0ZW6LpjavEvGlfOtfRLNf/jX+ZTs=; b=ulWsGmyQEylC0ouVFn/pgB onYBIEGAOiKH0u76zK4ISqr/Gc1c4RbfCLHQFWYOeUwhORL/NMyHU81hU+9AMldN LGwhM5QYXAjWaEFNAtV3uznUbzSG8NMsFApuM+yEdTzClXUuyaxmRYZ7fyD1wf5W sLueNqrIGw4uxAMFdS3kxhEhnq7+DljkOad/7OBnmQTq4nViSlD8OzxlPIB/Hg6e XhBtAtqfLnFiPKbPLy7Cb0Gnnm6/Rr1DOmcTd39On3AMsauQJan/JoiMlQBN0EXb 4sKHE7kVASTAJNaKZ7wmybPzIao8/nMAjDG82sEX6MbkYFURcL4Yzvw09rPmTyeg ==
X-ME-Sender: <xms:9P58Xac0GqzhMhB1V4t9dprt1l6GkeKiatbDYjZ4upC6671Vw18Cbw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrtdelgdekgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgfgsehtqhertd erreejnecuhfhrohhmpedfvehhrhhishhtohhphhgvrhcuhghoohgufdcuoegtrgifsehh vggrphhinhhgsghithhsrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdgtohhmne curfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhsrdhnvght necuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:9P58XYdqj8-AS5BJYzfgBVDSdmwG1aTC0V9jl7N1C81s4u-JI7PfNA> <xmx:9P58XWiS5EF3BqcGc8VVgRN3O_9Sg6EiSqIvqLGBl0eCXm2ewTSVUw> <xmx:9P58XcTPuqBWwECXOFmDz0E7flPW6U_4I4IQFFt1Kilx4VdLDMsdxw> <xmx:9P58XYH4d9aZBQb3BRizUez4ZwL11QswkfRomnHWNarB1SHLr8m-BQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 575513C00A1; Sat, 14 Sep 2019 10:53:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-237-gf35468d-fmstable-20190912v1
Mime-Version: 1.0
Message-Id: <e484c148-d64b-4538-9145-85e0363b0cc9@www.fastmail.com>
Date: Sat, 14 Sep 2019 07:53:17 -0700
From: Christopher Wood <caw@heapingbits.net>
To: "TLS@ietf.org" <TLS@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2Y8tx4HkjpYiyQwjCxZu7_dyXQY>
Subject: [TLS] Binding imported PSKs to KDFs rather than hash functions
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Sep 2019 14:53:44 -0000

Hi folks,

Martin reviewed the external PSK draft [1] and filed a couple issues [2,3] that are worth discussion here. I’d like to call attention to #16 [3] in particular. 

TL;DR: Should we bind the importer to a KDF rather than a hash function?

Currently, the importer draft assumes that an external PSK is optionally associated with some hash function, and, if not, assumes SHA256. The importer uses this hash function when deriving the imported key. In particular, it’s the hash function used for HKDF-Extract and HKDF-Expand, which runs over the external PSK blob and the constructed ImportedIdentity to produce a unique, imported PSK. ImportedIdentity is the structure that contains the external PSK identity, a protocol label, and target hash function:

struct {
  opaque external_identity<1...2^16-1>;
  opaque label<0..2^8-1>;
  HashAlgorithm hash;
} ImportedIdentity;

The issue raised pointed out that the (protocol label, hash) tuple effectively identifies a KDF. (Martin, please correct me if I’m misinterpreting your comments!) Thus, perhaps it makes sense to replace this with something simpler, e.g., 

struct {
  opaque external_identity<1...2^16-1>;
  uint16 protocol_version;
  uint16 kdf_identifier;
} ImportedIdentity;

Where ImportedIdentity.protocol_version is a code point (e.g., 0x0304 for TLS 1.3) and ImportedIdentity.kdf_identifier is a unique (registry-defined) KDF function (e.g., 0x0001 for HKDF-SHA256). If we did this, a couple interesting questions arise. 

First, should we keep using HKDF as the importer KDF? Note that the current ImportedIdentity.hash field is what diversifies imported PSKs by hash function. The actual key derivation still uses HKDF with the hash function associated with the external PSK. (SHA-256 is assumed if none is specified.) If we replaced ImportedIdentity.hash with ImportedIdentity.kdf_identifier, we would still get this diversification, since each target KDF is bound to one hash function. However, should the KDF corresponding to ImportedIdentity.kdf_identifier be the KDF used by the importer for derivation? That is, let’s say I have an external PSK "epsk" that's associated with SHA-512. Moreover, let's assume ImportedIdentity.kdf_identifier = 0xFEFE, which corresponds to some KDF called MySpecialKDF. Should the derivation step be this?

epskx = HKDF-SHA512-Extract(0, epsk)
ipskx = HKDFSHA512-Expand-Label(epskx, "derived psk", Hash(ImportedIdentity), Hash.length)

Or this?

epskx = MySpecialKDF-Extract(0, epsk)
ipskx = MySpecialKDF-Label(epskx, "derived psk", MySpecialKDF.Hash(ImportedIdentity), MySpecialKDF.length)

Or something else entirely?

Second, keys need to be imported for each supported ciphersuite and corresponding hash function. How would we specify that if we now speak of importers in terms of a target KDF?

Chris (no hat)

[1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer
[2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/15
[3] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/16