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

Achim Kraus <> Mon, 21 September 2020 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F13D83A0B51; Mon, 21 Sep 2020 11:13:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 s4lw9uqdVpoZ; Mon, 21 Sep 2020 11:13:34 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 340023A0B59; Mon, 21 Sep 2020 11:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=badeba3b8450; t=1600712010; bh=c6pomGufOxXjwPtoNanWtR+SCMF2tey6dwXlCXSC/xw=; h=X-UI-Sender-Class:Subject:To:References:Cc:From:Date:In-Reply-To; b=L/HT9a7QrGw93Zg2x2y6YrCOgt2ckxOyKALVolsJs4l0hqPaN0QTzBQjiIO+wzSkr kXmOq/Cj7FjhurGCnSgCYFjH7MX5/o18Sw5vs5mYL/smlT9ShHnjTWde/QS604qO3+ 00VhNT4lJJ714g4MhInfwnly2QqM6Ql4+ZhUrhcI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [] ([]) by (mrgmx104 []) with ESMTPSA (Nemesis) id 1MbzyJ-1ktCIn1tJX-00dSjE; Mon, 21 Sep 2020 20:13:30 +0200
To: John Mattsson <>
References: <> <>
Cc: Hannes Tschofenig <>, "" <>
From: Achim Kraus <>
Message-ID: <>
Date: Mon, 21 Sep 2020 20:13:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: de-AT-frami
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:RKaxbURNYwM4bvKBc+kQ0zCBaQIiJ05tvkjJ6pmVuwF/PVoxdpg f74mGXetmnKmRWU5oFPmd5GjmZNUhx1OUY/cVmH3MzQDDsjP4pJRnTGeKp3icKznOH2dkRn i+yJNrCKlylMMvBWpYbE2pH/kZr+xxeRbUY4p17OobJGoGfjXZIRB91oiCrB9RGKMW1/Xyr QOTBdfmqQ+eiachrHSB1A==
X-UI-Out-Filterresults: notjunk:1;V03:K0:NT0udcNmlWk=:6IG0J9TM1NhnIRMSq8TTnp FnuAayysYDnZOwVfxhiPVyxR3ri5/LLd5QO+BbNWdI6YrQ6aR/FseDMRvs/4oePitkpomKiND bBnJUdax9fRuJfSu+VyXYXbPca97Wo7ib/Ppu2FT7d4FJEkII4DILDOmkNIh8fBneOQOYVXOx OJpngLUKJCvsNDL1hfZsFxaRYXlTMuxDe/sPHCgfa4KXvHdXMbpzk/ts8cOFJpEa7ySKPspuT 5gjI2QL9EMJ8+gia3ZpW/T+g9gIP7U8fb7Y4YOpGrLHJEeAUFHJXz8FTmXF4RhynaGwn+J5OD xX94Wxf0vXGq708KgH1SBo7XL1G20apUYC68CRv/9YnYD7+6UDcrAcaHD6D7bgRz0dI7MlQoH ZRMWjXC/fVcBe/+S10cEIv6akRrwa3IYwOsYv7O9cKDsThUNXEIr8G2rEipEPXAmo4YICuxQR A0fhlYDadUEdmlBwGhkL53TYHkNa2DOe/plQpJl4GPFuXwTHq5ikHBacjEPr0g+wPlFaOIDz0 9MVvzo2qx1Zwk0tDye2pqc9w3QK4hsNcsNA6XSVL4EOoszT6Kv5L61lAd++3/eZjf2p51+kuT gC2tlMt9RATZVgJxIjPpJx7wbcFdfjkbgmfd7Su6xzi2U88WnGvo8Q2b/vPOH/qZaZvwu8UaG GkinQF2/0znEMbNGQRpwZ3k263YdBENgxUinTSkhYCFkI5aZkt4/nr8SwVsc2MlpsxR69X+1O nYUBrrRoMxJJqthnb+d94Xb4bejs3w34f+jWGHjGdWMeN5v6LAO6B0mxnTq+wAVqKGKFQrEVr oGYCqJl77D5vCiH2DIlZ5Vwe7C+p2bIzBFTFxlhgSLBfiQ/DNlYZWiGPnxYXsWpknWOA0flDe YUOxrm0rTlIiRin67c6PHfsu0n3XG6ctjtvbdrS+HARuGy78cea7Pn7JUXNqdjumkZgQ3gXQA wXA0qrNTCWtCzQrvk2HzVKp+gQ6ASXqYg7Yzlx3m50Ns5efspHT6KZs9JMhBktdMoO3uwbjPw v98N+p2cRF4n4e5g2GLqGgER7TuYKneqYMsertdSqx1RA8i12RVS/OBZKLUPpwnUQ8ZgknQhV cOnvhZtJZ0nv/MnVFFVbMRC0q6NSICpJEG9bvrtH2dWn/gU9lX2z06w08YLV5nQ1Dx+uC5qDZ DFikPf/VA+nITgoyK6iKKaOqgGHrLuCXH8qE7uTwaoIpuLhMBXB0THuPok2ottIW5pJvyr9BC IKPb8cGSuRd1uAPSyJtu9rttJF6LPOUEpMNKJ2g==
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: Mon, 21 Sep 2020 18:13:41 -0000

Hi John,

I can only fully agree with Hannes's arguments!

PSK is in my experience for some constraint devices currently the only
choice. Devices, which are able to execute a PSKs with ECDHE handshakes,
will be able to use RPK.

I'm not sure, if sometimes the arguments, not to recommend something,
should be more differentiated. Pretty sure, outside IoT, there may be no
reason left to use that. But inside IoT, it may take some more time
until almost all device can use it.

best regards

Am 20.09.20 um 13:18 schrieb Hannes Tschofenig:
> John,
> The use of plain PSK makes a lot of sense because it provides the lowest footprint solution for really constrained systems. Given that the LAKE group wanted to focus on constrained IoT devices makes the decision by the group questionable.
> As you know, TLS 1.3 merged the handling of PSKs previously found in three different RFCs, namely session resumption, ciphersuites with PSK, and session resumption without server-side state into one solution. As such, there is not even extra cost associated with external PSKs.
> I have been arguing that a solution that uses PSKs with ECDHE, as you proposed in RFC 8442, is less useful because very constrained are not going to use the asymmetric crypto needed for the ECDHE. Those deployments could instead go directly to a raw public key solution instead.
> Ciao
> Hannes
> -----Original Message-----
> From: TLS <> On Behalf Of John Mattsson
> Sent: Saturday, September 19, 2020 1:30 PM
> To:
> Subject: [TLS] The future of external PSK in TLS 1.3
> 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.
> LAKE recently removed PSK authentication completely as it does not produce smaller messages and comes with severe privacy and deployments problems. Increasing code size (a few kB) and slightly increased computation/latency was not seen as a big problems.
> Looking at the IANA TLS registry, I am surprised to see that psk_dhe_ke and especially psk_ke are both marked as RECOMMENDED. If used in the initial handshake, both modes have severe privacy problems, and psk_ke does not give PFS, thus making pervasive monitoring much easier. If groups keys are used, additional security problems arise. All TLS 1.2 cipher suites without (EC)DHE has for good reasons been marked as NOT RECOMMENDED.
> I have recently seen several people arguing that the inclusion of PSK in TLS 1.3 means that the use external PSKs are now recommended. I don't think that was the intension of the TLS WG.
> I strongly think psk_ke should be NOT RECOMMENDED, except for resumption. Irrespectively of what ‘Y’ in the recommended column actually means, people are and will read it as recommended to use.
> Cheers,
> John
> _______________________________________________
> TLS mailing list
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> TLS mailing list