Re: [TLS] Universal PSKs

Jonathan Hoyland <> Fri, 15 June 2018 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B34F1130E35 for <>; Fri, 15 Jun 2018 09:20:52 -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=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SmYuhGTIf0Kv for <>; Fri, 15 Jun 2018 09:20:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 977EA130DC0 for <>; Fri, 15 Jun 2018 09:20:50 -0700 (PDT)
Received: by with SMTP id 59-v6so6777472uas.5 for <>; Fri, 15 Jun 2018 09:20:50 -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=gGD/j6f9fKHzEpaV+Pzhgtrj/ezQMys4J8sqVFVGUmM=; b=iIog+w588LcV+vr9gNm3HwY8Yf+WoDG+bDuKb1Y39PMNQ/MPs8leK4kyYqIxO5a0+2 G2+Otq8QSmEFa+zHIq80sWkeFUVJESDtdIkXjfuqlYBec2ZjLcERxTnDerlozlvUOanB oaW/qDWTq1n85PSqglw6rEZfxapUs2wG9hrhREBwz4ja9rjpq1Bk/9vVWCoDkrjpD3Lk BI83WtnK67aMbMYojfG4Zu53GRAEILzrpByP9FuLu4Ei4MthVJzvgv1bkLBUDxpMN26y JjpAz7vHbtoVIZhoFy75NSJkMJE+7WELaCwq1kE6x/y3uwUU7up8f+LrBZUElQ/Jkhea k0fA==
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=gGD/j6f9fKHzEpaV+Pzhgtrj/ezQMys4J8sqVFVGUmM=; b=QMUF78E3OdSWqrIgmUfraq3YCZwh4zkzKauk6t7Wga6MEQzM+PCzIvoS+UfenhDrub 9GXC/donhUS9A4ifavdbwiCmW5XD2FlsSEeWy0JxG2LdvAw4fkIRTqg3PZE4+af5/63d 53skJokrpt3AinUBXg5KFu2Gg/XHOqPe8cpbmHzJRcWT4rBDrcoSo79Z00lrY6QO6Cs/ C+4QSFkOXnhwe3FH7tSshCsKD7pyjuT6xSi3RhXrn0GgxgYA41KiU5KxOrS9weJtvgku 9bG2Pi/MEQaetY6uvzOXwvk7n5PLiY2ceyudC40IDP/6SPL7nVQ55hoAPJsKgV6BvUvO mWCQ==
X-Gm-Message-State: APt69E2Ai5cRHcAbgjFYf4Y6/FxE2boZsJsm9AoRQG7Wae1hpv2RCVHh ZxA1UJRGJ8IHCGoIV5Rb/odOohUPY64Gk9zT0kkvHA==
X-Google-Smtp-Source: ADUXVKJzKE0mGk77Bq3rsHC+hcMZO6EFaEg3m+LcUIFAJRWOCKh4u/zHSgqvV4n+SVg/dIhStcXK360wnOXJYYYsYYk=
X-Received: by 2002:ab0:1b22:: with SMTP id d34-v6mr1565107uai.176.1529079649634; Fri, 15 Jun 2018 09:20:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Jonathan Hoyland <>
Date: Fri, 15 Jun 2018 17:20:39 +0100
Message-ID: <>
To: Benjamin Kaduk <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000598ffb056eb099a3"
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 16:20:53 -0000

Channel bindings are generally just horribly named.

The `channel` in that case would consist solely of the agreed key, and
agreement on it would prove that not only was that the key, but also that
nothing else was established.
Therefore you wouldn't be able to convince one side that it was just a
manually entered key, and the other that it was a TLS 1.2 PSK, which is
obviously a plausible threat.



On Fri, 15 Jun 2018, 17:13 Benjamin Kaduk, <>; wrote:

> On Fri, Jun 15, 2018 at 05:26:33PM +0200, Jonathan Hoyland wrote:
> > Agreement on a channel binding in the identity would prove, amongst other
> > things, agreement on the KDF used to derive the PSK, whereas the TLS
> > handshake proves agreement on the PSK itself, but says nothing about the
> > derivation of it.
> > This way means you don't have to worry about collisions between hash
> > functions, as long as the channel binding is correctly constructed.
> While this is an interesting way to think about things, it's unclear to me
> how general it is for framing the problem.  That is to say, there is not
> necessarily a "channel" used to provision what TLS 1.3 calls "external
> PSKs".
> My model for them includes an administrator typing a hex string into a
> configuration
> file on both ends of the connection, or a manufacturer burning a key into
> for an IoT device -- what would the "channel" be those cases?  (Or do I
> completely
> misunderstand what you're trying to do?)
> -Ben