Re: [TLS] The future of external PSK in TLS 1.3

David Woodhouse <> Wed, 23 September 2020 13:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0907A3A0995; Wed, 23 Sep 2020 06:54:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 yRyBLMvzgsGq; Wed, 23 Sep 2020 06:53:57 -0700 (PDT)
Received: from ( [IPv6:2001:8b0:10b:1231::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2CCFB3A0990; Wed, 23 Sep 2020 06:53:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=merlin.20170209; h=Mime-Version:Content-Type:References: In-Reply-To:Date:To:From:Subject:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description; bh=X/kDHS99HApLhgE6MCZNmyTt/BjhLGGv/jLIYmw22FY=; b=Rd/G9zj64nrT/hJNLdEJWWkY/P NKeC+9w/bA6J9hMBBqmgfKrTxbayKfn0AFIHLueqhkwfUFA+vqW8Sk5UcApNAfMwthDHwwCnur7oT cxYsI5EsDLyH6GZeO7CQHsa1gPhjvG2DeecAjsdEo1LuQ75YSRQTS9Ws0/KDXK6dd4R4nmgcrnIQb omC9cWWcm7tAemnqyoKYaoK4f0pIRLZfdZkoECPjZQp4k807Rb8TwbbL9HfSxjxynF0uUkXGxeuUu ZUnl/gpnOwBIVVkniK1WXYe6hdM49nvWDocuPuDsgoCYLSbNEeq6mgWBMs8k9UycF5i7WsO4tqJtI pbAlRpFQ==;
Received: from ([] by with esmtpsa (Exim 4.92.3 #3 (Red Hat Linux)) id 1kL5DT-0002zW-EW; Wed, 23 Sep 2020 13:53:51 +0000
Message-ID: <>
From: David Woodhouse <>
To: John Mattsson <>, "" <>
Date: Wed, 23 Sep 2020 14:53:50 +0100
In-Reply-To: <>
References: <>
Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-wQwCZp68ndj+Qewpn2rn"
X-Mailer: Evolution 3.28.5-0ubuntu0.18.04.2
Mime-Version: 1.0
X-SRS-Rewrite: SMTP reverse-path rewritten from <> by See
Archived-At: <>
Subject: Re: [TLS] The future of external PSK in TLS 1.3
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, 23 Sep 2020 13:57:50 -0000

On Sat, 2020-09-19 at 11:30 +0000, John Mattsson wrote:
> Hi,
> Recent discussions in 3GPP, ACE, and LAKE about the use of symmetric
> keys for authentication and key exchange made me think about the
> future role of external PSK in TLS.
> I authored RFC 8442 because I believe PSK+ECDHE is needed for legacy
> systems. Due to the major privacy, security, and deployment
> limitations with PSK, I see little need to use PSK (besides
> resumption) in new systems, except for the use case in RFC 8773.

Some VPN protocols (e.g. Cisco AnyConnect) attempt to establish a DTLS
session in parallel with an existing TLS session, to avoid TCP-over-TCP 
where possible.

Cisco does it by fabricating a DTLS session (details exchanged over the
existing authenticated TLS channel) and then "resuming" it. Using this
method, the DTLS protocol version and all options are hard-coded when
the session is fabricated. This makes me sad.

In the open source implementation of client/server we have extended the
protocol to exchange a PSK over the existing TLS session, then
negotiate DTLS the "normal" way using that PSK.

That's a lot cleaner (IMO) and seems like a valid use case for PSK.