Re: [TLS] Binder key labels for imported PSKs

Jonathan Hoyland <> Wed, 06 November 2019 11:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2C91120864 for <>; Wed, 6 Nov 2019 03:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ktw5IG3QDs9X for <>; Wed, 6 Nov 2019 03:20:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F20F912085F for <>; Wed, 6 Nov 2019 03:20:35 -0800 (PST)
Received: by with SMTP id q21so15703789vsg.3 for <>; Wed, 06 Nov 2019 03:20:35 -0800 (PST)
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=Bo2r3S+hamY75dV1gxlyY+r5f95I09Sgu9/vrE77YAk=; b=AwDt33HC71ZeO0ydFcpz+4EQMEqhUA2K62JYcRgBZ/0Uyc6adPNnZB+TXH6MyR6u5C WH6DYxvn2DrNU8Rijimmc2T0iLpRzYEvpyxnE/4aHBoAAMnT4BhEb9RKbwQ716ARwR5T R4R1pRMTm+KpIAeAz0mpUW+wqWFMy9xb5duyNKAwOoLaBTDqOjAEnSm1sgimRmh9PV9i ailfEhnVQl2XmdeXocDOqSOZzw1rwmtccJRJDOyu4iSZlFKbfPr7oUV2KZrl6V3TagRm Mrjcsppud6C3OGr+N3jFx9kaj2Pc/5GNdREU38kQaLdpO1nFvWfk8tsmKqJWTZlYyOYT oNJg==
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=Bo2r3S+hamY75dV1gxlyY+r5f95I09Sgu9/vrE77YAk=; b=rfPDbHCaDHPoG7VhU7i1wuIZi9tbehfLSM4/6C8ohQyaT+tbBWI2+4cccq7c18I6gs ph1+kDGj3AWpfwuFqBXDcdU5xZfm6DFWZaqWb4hg/ETlr5f1meouwvmhgfMNP3TU9PvB K1i5qkoOexneuWzhyPXVqLh28mVMZ6byblBsFBB055RG/oJmKWi9ZwO/i7D4ci417ZbV d8Y+iqIOnR+4J3l55bQ7diav4jPhEGEKg6j6clXtl9xNiZpcg9RUb7CzVtJKs4iD9jns r213LkBgcLZCd75KWyDT1K/JHk5ThZQoV5I4TFV7BW7HdB9Z59gA3vFsKKKB+aJmFdFz 2q8w==
X-Gm-Message-State: APjAAAVjYBUTcg+VWaNNHsIlv5Q6DuXa2dYl29ZXtsG/LCgvYXm6pNE7 6CXHZkZ85p407H5Te1TaSmnwU3et67XQRpRLFCM=
X-Google-Smtp-Source: APXvYqyhHS6F9SWAiHA3f4DHSoDrZma/iAfUu4gO3owmcHn3woNqyQCxbDCb2iRxGsrGfvB1aLiSJ4z62PbaGWvy+v4=
X-Received: by 2002:a67:fc85:: with SMTP id x5mr987050vsp.148.1573039234569; Wed, 06 Nov 2019 03:20:34 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Jonathan Hoyland <>
Date: Wed, 06 Nov 2019 11:20:23 +0000
Message-ID: <>
To: Rob Sayre <>
Cc: "Salz, Rich" <>, TLS List <>
Content-Type: multipart/alternative; boundary="000000000000cb59fd0596abbc6a"
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, 06 Nov 2019 11:20:38 -0000

Hi Rob,

The situation we are trying to prevent is when both the client and server
think they have completed a handshake with each other, but disagree on what
In this case, for example, the client might have used a PSK importer, but
the server might believe the client has used a vanilla PSK.

This type of mismatch can lead to channel synchronization attacks, where an
attacker establishes two separate sessions, one with the client and one
with the server, that both have the same key.
There were attacks on early drafts of TLS 1.3 that you can describe in this
way (e.g. the triple handshake attack
<> or the
attack on draft-10+
Especially if we use later extend this mechanism to chain together
different imports we could introduce subtle and difficult to detect flaws.
This change reduces the potential for this type of problem.

A more direct reason for this change is to do with the goals of TLS 1.3.
One of the properties TLS 1.3 tries to provide (see appendix E.1 [p. 143])
is "Uniqueness of the Session Keys".
Without this change a client using a vanilla PSK that happens to have the
same PSK_ID and key as an imported PSK would produce the same session keys
as a client using the equivalent imported PSK.
This violates the desired property.

Does that make things clearer?



On Wed, 6 Nov 2019 at 02:08, Rob Sayre <> wrote:

> On Tue, Nov 5, 2019 at 6:03 PM Salz, Rich <> wrote:
>> > Do people agree that we want to prevent PSK Importers from being
>> confused with standard OOB PSKs and that we should do this by changing the
>> label used in the computation of the PSK binder key?
>> Obviously.
> For the slower folks on the list, such as myself, could someone explain
> why confusing these two types of PSKs would be bad?
> thanks,
> Rob
> _______________________________________________
> TLS mailing list