Re: [TLS] Universal PSKs

Jonathan Hoyland <> Fri, 15 June 2018 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E0C3130EF6 for <>; Fri, 15 Jun 2018 07:52:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cZ5Ylu5Cd23i for <>; Fri, 15 Jun 2018 07:52:43 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EB9BE130E4F for <>; Fri, 15 Jun 2018 07:52:42 -0700 (PDT)
Received: by with SMTP id s187-v6so5823261vke.9 for <>; Fri, 15 Jun 2018 07:52:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Wom6CuJ//YRh9XzhhtG32gRZ4mT5LwtciDzs/kRmZmc=; b=UjgajQaMb1APB23wbBu5x0HNNTmI6ko/7sXmoHwu/UFhjF//WBEox1wXvt+bWZP4w+ RPCS35SB2hOVSvz5eFfEy5mlRHhDW9JGol1pERXg3Iu8OsEhT2KeKi1waE3eH5dh8ErT FUvnq1YBxcYXPHtpxAcnUd0QeWA68jvbXyMYwHofgq7cnEwyvZyXX/0fh2KZpxh9yXES CSQQs9e72EKS+tGLS+CJo1dPlPAiiVs1qQ6x7mqFSq+db0qffdkrzFYH2jBMzuGT19BI qQ+eUwLUPAL0sTd1gvm3nkN+ddFaVic/Qyr2fRAtLvAN2JSe8E1Jsy7GZBn6drL3qbcO b+xw==
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=Wom6CuJ//YRh9XzhhtG32gRZ4mT5LwtciDzs/kRmZmc=; b=FrfkhmEa+3lNYPXOYzSRC8J/+uLph+t1Os3piGlVairgnmvUfkr3FgyW6oG8sg0sBY MZ1O+vOVNMAeSYEFYXI1pooKlhL0A3Z5oIZCg8Z7inYrQG+KjNPX2u695aC/3EhYLqVO f6QVe6tgyQKc6nLolRfjlQcrahGMkzeHAj+ZobE1pKpMIPdxN97SurMI1jv5trQG9ESJ /3BavSwSKfh2wj9JgYv/Pgdq0EIfTTR8Xviu7jXNmCHDNCjnLdBiICsoPYqPRFPzfH0T Yw/AhgvsYXOfa6lC5tRa+BGuYH5AKMMBjf2cnLBSzURAS283oH6sZEdTYJaAfWmTnKEH ZeSQ==
X-Gm-Message-State: APt69E3zcrK9zFFu6NBS/Jt1bx14Z3+ylxiUaQjsaPlshsSBvnWC7KP+ 4LYvhJjzS3JAQGdYTXjfFxvh+p3uCSef7HwZbEiIeQ==
X-Google-Smtp-Source: ADUXVKITQChpEjOFRHm/3ajuoJdTnWMKdFwLck8ADLIzsDqvVRngIquEGU2RgVBmZdTrAeucp1yibNYSTf9bK6OFk1A=
X-Received: by 2002:a1f:eb44:: with SMTP id j65-v6mr1152779vkh.14.1529074361918; Fri, 15 Jun 2018 07:52:41 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Jonathan Hoyland <>
Date: Fri, 15 Jun 2018 16:52:30 +0200
Message-ID: <>
To: "Salz, Rich" <>
Cc: Hubert Kario <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000002d67f9056eaf5ed8"
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:52:46 -0000

Is it not possible to construct a channel binding for whatever underlying
protocol was used to agree the PSK and use that as the PSK identity.
If the PSK was created in TLS 1.2 then that would be something derived from

The security of a channel binding is not dependent on it being secret, and
thus using it as the PSK identity is safe.

Doing this would prove agreement on the KDF used, and would be bound to the
handshake by the PSK binders.
Assuming that the KDF was something acceptably secure, this would mitigate
the risk of collisions between hash outputs, because which hash function
was used to produce the PSK would be an agreed value.

That would also require no changes to the key schedule, which is perhaps
lower risk.

This of course assumes that both parties agree that this is how the PSK
identity was constructed,  so it would probably need an extension.



On Fri, 15 Jun 2018 at 15:25 Salz, Rich <>

> >    that's not workable.
> It's not great, however
> >    the reason why implementations chose to use old API to provision TLS
> 1.3 PSKs
>     was to make the upgrade process as smooth as possible, disabling TLS
> 1.3 is
>     quite antithetical to that
> Disabling TLS 1.3 for those using 1.2 PSK's is unlikely to affect most
> uses, and seems the only way forward.
> Do you have an alternative solution?
> _______________________________________________
> TLS mailing list