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

Carrick Bartle <> Mon, 21 September 2020 16:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49A413A0A2E for <>; Mon, 21 Sep 2020 09:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.867
X-Spam-Status: No, score=-1.867 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 V81swxPpAviq for <>; Mon, 21 Sep 2020 09:19:15 -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 33C033A0A29 for <>; Mon, 21 Sep 2020 09:19:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1a1hai; t=1600705154; bh=mrEoHN6EW6p5I+OoVtWOnJTTC+D6Mogf6p5ImdGZjDs=; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:To; b=j16BY4ogdmNGcSk/41D68MchlRuZcOVy/s0EKbcMPnU18EBJHYwrl9aR9qgQdm9Pm A79UYN63y9ZQeidi2kdGeixor/s4eKelfaUCr2/9FS/rup1gKCzA60MrTZ1vd8TFpc zOziaptYITPhzpBPcEHnxCMSXgIghb0lj9AgbQ7JmUqDzPf3H3OUzKE4q438ZBFZEp 8ljg+uRMoHEloEdF4/ZKdOrryyXLfl2/PbATppyTntnPHJWeqWnuyvUnxiE3S4lfDW W+pGw9vRbo9OTzUZSH2VOArDFo1Z788adgeJ6TLP4DDhLMiXcFlR+1E9j3SPJXTG8/ bxzwLPp5UrF0Q==
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 35508A0037A; Mon, 21 Sep 2020 16:19:14 +0000 (UTC)
From: Carrick Bartle <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_69DEEC3D-48EF-4201-B818-E99E703E16E3"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 21 Sep 2020 09:19:13 -0700
In-Reply-To: <>
Cc: Carrick Bartle <>, Filippo Valsorda <>, "" <>
To: Hannes Tschofenig <>
References: <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-09-21_05:2020-09-21, 2020-09-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0 mlxlogscore=991 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2006250000 definitions=main-2009210115
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 16:19:17 -0000

> Can you justify your reasoning? 

Which part?

> On Sep 21, 2020, at 2:22 AM, Hannes Tschofenig <> wrote:
> Hi Carrick, 
> Can you justify your reasoning? 
> The challenge I have with the work on IoT in the IETF that the preferences for pretty much everything changes on a regular basis.
> I don’t see a problem that requires a change. In fact, I have just posted a mail to the UTA list that gives an overview of the implementation status of embedded TLS stacks and PSK-based ciphersuites are widely implemented.  
> Ciao
> Hannes
> From: TLS <> On Behalf Of Carrick Bartle
> Sent: Monday, September 21, 2020 5:31 AM
> To: Filippo Valsorda <>
> Cc:
> Subject: Re: [TLS] The future of external PSK in TLS 1.3
> I'm also fine with marking psk_ke as not recommended to be consistent with the non-PFS ciphers, but there are plenty of valid use cases that justify keeping dhe_psk_ke as recommended for external PSKs. Several of these use cases are detailed in draft-ietf-tls-external-psk-guidance-00.
> On Sep 19, 2020, at 9:00 AM, Filippo Valsorda < <>> wrote:
> 2020-09-19 13:48 GMT+02:00 Peter Gutmann < <>>:
> John Mattsson < <>> writes:
> >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,
> PSK is used a fair bit in SCADA.  There are no privacy problems there.  So
> just because there's a concern for one specific environment doesn't mean it
> should be banned for any use.  In particular, I think if a specific industry
> has a particular concern, they should profile it for use in that industry but
> not require that everyone else change their behaviour.
> Indeed, if the SCADA industry has a particular need, they should profile TLS for use in that industry, and not require we change the recommendation for the open Internet.
> Setting Recommended to N is not "banning" anything, it's saying it "has not been through the IETF consensus process, has limited applicability, or is intended only for specific use cases". SCADA sounds like a pretty specific use case.
> I don't have a strong opinion on psk_dhe_ke, but I see no reason psk_ke wouldn't be marked N like all suites lacking PFS.
> _______________________________________________
> 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
> <>
> <>