Re: [TLS] Universal PSKs

Nikos Mavrogiannopoulos <> Fri, 15 June 2018 11:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 415DD130DEA for <>; Fri, 15 Jun 2018 04:37:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RT2LzU5nVwh0 for <>; Fri, 15 Jun 2018 04:37:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 99BB7120049 for <>; Fri, 15 Jun 2018 04:37:56 -0700 (PDT)
Received: by with SMTP id j15-v6so3345613wme.0 for <>; Fri, 15 Jun 2018 04:37:56 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=b0CcQbUh+vWZJW/VVSYiTUNAfRBqI5TyN1uAUXWWOWI=; b=ivQoY92Xjr11VIkoLXNm0dgINKp+nujDEaBACwcf+hfgIMPY2MNCz0R/DbywuoLRWb tEob7e11aKVMFuropLFR+U+Y9kawP/MxuWm1UmT+76FiT/VN261xkooWYzloYDgw6wHs P4tKonGBgUvUDU1bftVZShel/UCR4DUboiGI1IvtXb06IkVfqUORDQK8m8BS05Xv4tFl q03PU+uOejODv0gE+F1jDBgw7BYzorLJAbkN0obD8mtfDIYwihses4f5GZZrpF4chHtY bX6NpJeuSTq06HioLwytl0DeFG0WLzdFfKH0r2nsv8XJfL64HgLtivxKWvn+GTsFybeO zAAA==
X-Gm-Message-State: APt69E0ohzm46nV9Bt4xSXE9Gk3pjws/C8CT8lw/tAvKBLzwwPj2k4s4 iKGMrvtSX5lDrAnuBp381gI61A==
X-Google-Smtp-Source: ADUXVKJvRH2Fk6mW6BDwToZy805YlP0WcXpTJ/5nu65HZvwMnvM01Tfm8nvwYhWZuGuG3kABVtwJzA==
X-Received: by 2002:a1c:d2cb:: with SMTP id j194-v6mr916457wmg.129.1529062675017; Fri, 15 Jun 2018 04:37:55 -0700 (PDT)
Received: from ( []) by with ESMTPSA id e2-v6sm9302747wro.97.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 15 Jun 2018 04:37:54 -0700 (PDT)
Message-ID: <>
From: Nikos Mavrogiannopoulos <>
To: David Benjamin <>, "<>" <>
Date: Fri, 15 Jun 2018 13:37:53 +0200
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] Universal PSKs
X-Mailman-Version: 2.1.26
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: Fri, 15 Jun 2018 11:38:00 -0000

On Thu, 2018-06-14 at 15:46 -0400, David Benjamin wrote:
> Hey all,
> So TLS 1.2 has a mechanism for PSKs. We attempted to mirror it in TLS
> 1.3 via the external PSK mechanism, repurposing the resumption flow.
> But the security proof requires PSKs be associated with a specific
> hash for key separation. We use distinguishing labels in the key
> schedule, but if that key is fed into a completely different KDF,
> analysis must additionally consider interactions between the KDFs.
> The hash constraint, however, makes it difficult to actually use
> external PSKs in applications. Usually the TLS stack and its
> configuration evolves somewhat independently from the calling
> application. But now the PSK provisioning process must short-circuit
> part of the TLS parameter negotiation, despite it likely being
> implemented in a separate library altogether. This is a leaky
> abstraction.
> It also complicates server parameter selection. We've found the
> cleanest algorithm is selecting the cipher suite first, and then
> ignoring the PSKs that don't match. This is simple and avoids weird
> behavior if a session is renewed across preference changes. However,
> this only works for resumption PSK: if the session mismatches, a full
> handshake is always an option. With external PSKs, the application
> usually expects the PSK to be mandatory.

> Finally, some libraries (e.g. OpenSSL) already TLS 1.2 PSK APIs and
> wish to transparently upgrade to TLS 1.3. The specification does not
> explicitly say if a TLS 1.2 PSK may be used directly as a TLS 1.3 PSK
> and I believe some implementations are doing that. However that
> violates TLS 1.3's key separation assumptions in the same way as
> mixing hashes: the TLS 1.2 PRF is not the same as HKDF.

I don't think that TLS1.3 has strict key separation assumptions, and
they are nowhere spelled out. For example, RSA keys can be used for
RSA-PSS or RSA PKCS#1 1.5 signatures or RSA encryption.

> It's a bit late to completely redo external PSKs in 1.3, but I
> believe we can fix this in a separate draft. The draft below proposes
> "universal PSKs" which derive independent hash- and version-specific
> secrets for TLS 1.3 (and later) as needed. For existing TLS 1.2 PSKs,
> it includes a compatibility derivation to go from TLS 1.2 PSKs to
> universal PSKs.
> (Thanks to Karthikeyan Bhargavan, Matt Caswell, Eric Rescorla, and
> Victor Vasiliev for discussions which led to this design. Any
> mistakes in it are mine.)
> Thoughts?

It feels that's this is too little too late. Implementations which
support PSKs will switch to TLS1.3 irrespective of this proposal. If
this proposal takes on, we will have some implementations which support
universal PSKs and others which don't leading to interoperability
problems which we wouldn't have otherwise.