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

David Benjamin <> Wed, 23 September 2020 15:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 32BF03A11AA for <>; Wed, 23 Sep 2020 08:47:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.944
X-Spam-Status: No, score=-10.944 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] 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 WqbxBIBOyEkp for <>; Wed, 23 Sep 2020 08:47:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 979243A11A6 for <>; Wed, 23 Sep 2020 08:47:44 -0700 (PDT)
Received: by with SMTP id m15so7062269pls.8 for <>; Wed, 23 Sep 2020 08:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XnvlggdocXw1zMvP0ablzmHV3hZ4Ch3KnAzlCS6flhM=; b=IHygD/u7zJvz/lZ53P1F2aHb5yRc+/iNNEJegsXYuJQDUnBDzJ+SEl/E4Kp8o4u4c/ QiCrMTiY9ht3U3zMAjahT/wsSrqjCkK0I/vstJSKOox5m7ST5G+qxjonIFjo15RXBire ihkYLgHpHIEDBakbb7cjZiHD1tJCxhuvFaHrM=
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=XnvlggdocXw1zMvP0ablzmHV3hZ4Ch3KnAzlCS6flhM=; b=hJ2+Fm4uwSF1BtAsx9U+DhI9Ai+lqvDamjD892EOXyQ7dNfwcPZtv3qSjbwwiOXVqi DhVhHd2TLOAY4Ss2St2FvAo/3wCtkm/OOUkZKTohnlxJTICzcb92XR3GbmNEcBolE8G/ QYFtCi7w9Qr2RVhNOKXgcQWskgwYTMM6a1WwknWNf1UAyEKH4ZQDeUb+c8yW73BxWjTA qdAP9hsg+3ObIGTs+3EO+g+XQGE3Br60zFe62XeKKIsp6/rIT+t5ZAu8RMttIcPxherP mphwPOv6tqjwaaQunA4RylUtj4ocZpjfZwhbR/GkIVkNJ1dSRTENx/X/1yRpr5BHwsZ+ T7YQ==
X-Gm-Message-State: AOAM531NVHPrK6dZDTY4QBZxbnxY+rTsoOnh08jZ6YSV03PuyDweSPy1 ccJ6/gnVHDRqiHmaS3YddClhlhnjuYJFpUJCSnKL
X-Google-Smtp-Source: ABdhPJy/7wlis3eSmubUNGyvsp0Yb/sLtfsPXzEx8wDrP8mxU23OGUoppI6o0X4xs2aeJwu1/IsJqEFAijRL+o3FL5s=
X-Received: by 2002:a17:90a:67c7:: with SMTP id g7mr77473pjm.42.1600876063840; Wed, 23 Sep 2020 08:47:43 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 23 Sep 2020 11:47:27 -0400
Message-ID: <>
To: "Salz, Rich" <>
Cc: Hannes Tschofenig <>, Filippo Valsorda <>, Carrick Bartle <>, "" <>
Content-Type: multipart/alternative; boundary="0000000000001dd8e505affd0107"
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 15:47:46 -0000

There are two different code points involved in TLS 1.3 PSK, and I think
there may be some mixup here:
1. Whether TLS 1.3 psk_ke should be marked N
2. Whether TLS 1.3. psk_dhe_ke should be marked N

Avoiding psk_ke does not remove compatibility with any authentication
method. psk_ke and psk_dhe_ke use the same PSKs. The difference is whether
the handshake mixes an additional (EC)DH exchange into the key schedule.
We've *already* marked TLS_PSK_WITH_AES_128_GCM_SHA256 with an N, so it
seems to me psk_ke with an external PSK should be similar. Handshakes using
psk_ke with an external PSK incorporate no secrets in the key exchange
apart from a (often long-lived) external symmetric secret. Compromise that
secret, and all traffic ever authenticated with that PSK is compromised.
Resumption PSKs use short-lived keys, so psk_ke is less immediately
disastrous but given the equivalent construction in TLS 1.2 has forward
secrecy issues <>,
marking it as N across the board seems a good idea to me. (BoringSSL does
not implement psk_ke for this reason. Looks like Go and NSS do not
implement it either.)

psk_dhe_ke I suppose depends on how one interprets "specific use case", so
I don't feel very strongly here.


On Wed, Sep 23, 2020 at 11:37 AM Salz, Rich <rsalz=> wrote:

> I agree with Hannes’s reasoning.
> I am also concerned about devolving TLS to be just Web browser/server.
> _______________________________________________
> TLS mailing list