Re: [TLS] Universal PSKs

David Benjamin <> Fri, 15 June 2018 14:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BC92130E4F for <>; Fri, 15 Jun 2018 07:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.951
X-Spam-Status: No, score=-9.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] 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 8kDlql0wMjWW for <>; Fri, 15 Jun 2018 07:57:07 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 27B57130F34 for <>; Fri, 15 Jun 2018 07:57:01 -0700 (PDT)
Received: by with SMTP id w23-v6so5744986qkb.8 for <>; Fri, 15 Jun 2018 07:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jp0gL7HwkLyir0K6JceemyQcHHN3ivD+agUn1E+Ht0g=; b=EVBuNKyrOq4ErEVbheXQWVtN+XX/opfG33ppv3bDnN1r/2013AdMC2744Dcyogm25c kFX0Y8wYhrrPmq8dkTRVqO8ds4QPAb+s95Kww67mQocgxXS2w7KnMahjae5BBvUe4Vnc d515yKlJHBrlWlMe0Xs4tKkiJ+nXn+VzpF8hM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jp0gL7HwkLyir0K6JceemyQcHHN3ivD+agUn1E+Ht0g=; b=YezXKLj2+N6p6nhbgG6AyX+38BXeOYr+ia0QIK2eFAPkX7/arh8FICwY8DSbMPQHKN cqQQ5/S6I+1fmJZuL9g6HC3eIDPdGv36EJCWXHTsAkdASFZbiOan0ghoHUBkVRqlp3vk G0vkA60h3mb7EAjysiJSGo488VVrxm7T7s59Qnb8s5KyzwitEkHB1y280lQlduxAfOdx 58QRkMmRlD9mHQBtuDotKnl4/vjCqEainJeQEshLVwLuRqH0i+1e8o+QbMWFgXbOksnh ZAyeozQLz4fT3ee3JEtCgZD6cEhVOHMs3x7aCClaes1+giwlf0M9s3efw3sZwh1WQbhz +dvw==
X-Gm-Message-State: APt69E3pK68TReZhLuyAJOnXBGVwDO8GxW7YztQo5KTT9VOVL/5Vt+YJ dtGhi6ESSzuBDNWP+U+aE9B2WuBWwoDWKTCC0bGkAsE=
X-Google-Smtp-Source: ADUXVKLXRHvGlbvftOP9K95BFONG0h3OhZtm0zKexjp3j9vQcc4ZzgkANS4zotreKk1tthWIaZR8naLHH5u26OJAueY=
X-Received: by 2002:ae9:c008:: with SMTP id u8-v6mr1659142qkk.85.1529074620097; Fri, 15 Jun 2018 07:57:00 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Fri, 15 Jun 2018 10:56:48 -0400
Message-ID: <>
To: Nikos Mavrogiannopoulos <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000009195e1056eaf6d6a"
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 14:57:14 -0000

On Fri, Jun 15, 2018 at 7:37 AM Nikos Mavrogiannopoulos <>

> 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.

I think it's a little more complex than that. Keys used in multiple ways
are affected by interactions between those uses, so formal analysis tends
to want to exclude these cases. So, yes, ideally we would separate every
key everywhere. But, as Hubert notes elsewhere in the thread, we wish for
the TLS 1.3 upgrade to be as smooth as possible, which includes being able
to reuse any externally-provisioned keys (RSA, symmetric, or whatever).
These two desires are in tension.

For stuff like RSA, we don't have easy ways around this. If you have an
id-rsaEncryption key---which is common---that's what you've got. So the RFC
4055 and TLS 1.3, for practicality's sake, allow this.

For symmetric keys, we have more flexibility in playing games deriving keys
with labels. The entire TLS 1.3 key schedule is a tower of this stuff. To
that end, TLS 1.3 *does* include a hash-matching requirement for PSKs.

However, in doing so, we failed to account for similar practicalities with
external PSKs, both with existing TLS 1.2 PSKs and also clean abstractions
for new uses. This draft is an attempt to fix this.

> > 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.

Right, I think that's why we should get a quick clarification in the spec
that 1.2 PSKs shouldn't be used directly in 1.3 and a fix for this is
forthcoming in a later document. (Assuming, of course, we all conclude that
is how we want to do this. I chatted with Karthik about some of this when
writing the draft, but I certainly may messed things up or misunderstood