Re: [TLS] PSK in 1.3?

John Mattsson <> Mon, 23 February 2015 14:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 782C21A00EC for <>; Mon, 23 Feb 2015 06:55:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nds99QE8kjBV for <>; Mon, 23 Feb 2015 06:55:37 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7B7B1A1A1D for <>; Mon, 23 Feb 2015 06:55:36 -0800 (PST)
X-AuditID: c1b4fb2d-f79fc6d000001087-53-54eb3f67d032
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BA.6A.04231.76F3BE45; Mon, 23 Feb 2015 15:55:35 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Mon, 23 Feb 2015 15:55:34 +0100
From: John Mattsson <>
To: Dan Harkins <>
Thread-Topic: [TLS] PSK in 1.3?
Thread-Index: AQHQTazXvws9Rg+evUOpC4fBWiiT/Jz+RW8A
Date: Mon, 23 Feb 2015 14:55:34 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_17E2EE7370484553A08A45D0DB34A88Cericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM+JvjW66/esQgxsfBSyW/vvCYtH2ooXJ 4tP5LkYHZo8lS34yeTzb/ZLF49HsO0wBzFFcNimpOZllqUX6dglcGdvXahT0/GOs+LtPqoHx ym3GLkZODgkBE4lj61awQdhiEhfurQeyuTiEBI4wSizY/YwVwlnCKLG2bzorSBWbgIHE3D0N YB0iAqoSR9/NZgexmQViJP4dXAMU5+AQFpCTuDOtBKJEXuLMtpusIGERASOJ+d8rQcIsQJ3z W5cwg9i8AvYSm1c/Y4FY9YdJYu6m1UwgCU4Bb4mrn/eDrWIEOu77qTVMEKvEJW49mc8EcbSA xJI955khbFGJl4//ge2SEFCSmLY1DaI8WaJhXTs7xC5BiZMzn7BMYBSdhWTSLCRls5CUQcT1 JG5MncIGYWtLLFv4mhnC1pWY8e8QVI21xMM9XYzIahYwcqxiFC1OLS7OTTcy1kstykwuLs7P 08tLLdnECIzMg1t+6+5gXP3a8RCjAAejEg/vhumvQoRYE8uKK3MPMUpzsCiJ89oZHwoREkhP LEnNTk0tSC2KLyrNSS0+xMjEwQmMQ7Xt5/d9KrENjF4aen95uzBjz8SpMU+eqTuzRu+/VB0T vaFq+oeLvLXNrmUePs+7HMQ/dqTah07+a7s978GsN3fqr298dan3+vPO51Xpx1Q3slt9vHtn q2hAavGDsAlmioWKP2ctLduzz+bLPs8l3/9u7j2st3Kves2/o8dz3vK5zy2v//A7WEyJpTgj 0VCLuag4EQAc3Zg2rQIAAA==
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] PSK in 1.3?
X-Mailman-Version: 2.1.15
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, 23 Feb 2015 14:55:40 -0000

PSK cipher suites are not only used by small devices. They are well used (by e.g. 3GPP) for both terminal <-> server as well as server <-> server communication.
Seems to be confusion about PSK and passwords in the discussion. Passwords are generated by humans, offer low entropy and are weak. PSKs are not generated by humans, offers good entropy and are not weak.
Any PSK or RSA implementation that correctly used a good PRNG would not be susceptible to dictionary attacks. E.g. TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 is a perfectly fine cipher suite.
Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the authentication and key agreement discussions should be separated.

On 21 Feb 2015, at 09:03, Dan Harkins <<>> wrote:

 Hi Sven,

On Thu, February 19, 2015 7:41 am, Sven Schäge wrote:
I was just reading through the TLS-PSK related discussions so far and came
across your post...

2014-10-20 14:13 GMT+02:00 Dan Harkins <<>>:

On Sun, October 19, 2014 7:35 am, Yoav Nir wrote:

I also understand that in practice, PSK ciphersuites are used only by
small devices, whereas the web and SMTP and other things never went
it. But the standards donââ,¬â"¢t say that. They donââ,¬â"¢t say
that PSK
ciphersuites are especially for constrained devices. So if we insist
the same TLS 1.3 be used for both, and we donââ,¬â"¢t want to say
that PSK is
for weak security, then we should have a good story of why PFS is not
needed for PSK uses, whereas itââ,¬â"¢s essential for all RSA uses.
If I
understand the mechanism correctly, PSKs tend to be long-lived, and a
subsequent compromise of a PSK (even if it is expired at the time of
compromise) allows an attacker to decrypt the content of a TLS

 The non-PFS PSK ciphersuites are no different than the widely
discredited, and easily cracked, WPA-PSK mode of WiFi security. It would
be a really bad idea to continue with these ciphersuites in TLS 1.3. But
issue is not just PFS (or the lack of it), it's that PSK ciphersuites
susceptible to dictionary attack.

So either we believe that PSK compromise is unlikely, or we believe
the data in a connection with a PSK ciphersuite is not
If we donââ,¬â"¢t, weââ,¬â"¢re saying that weââ,¬â"¢re just piling
on security
nice-to-haves because we think the users can handle them.

 There's no way that the protocol can be defined to justify that
What you're talking about is how people end up using the protocol and
that is entirely out of the power of this WG. What we can do is to make
TLS be as _misuse resistant_ as possible. And to do that we should not
allow PSKs in TLS 1.3 unless they are used in a PAKE.

 By the way, I'm surprised that no one is expressing outrageous outrage
at the lack of a security proof for PSK ciphersuites.

Perhaps you might find


 No, I don't find that particularly useful. It doesn't assume a powerful
active attacker that is able to enumerate, off-line, from a database of
secrets that the PSK is likely drawn from. It's saying that if only the
and server know the PSK then the resulting secret will be known only to
them too which is not useful at all. It places the security of the protocol
in the hands of the people using it and that means the protocol can be
really secure or not secure at all. And therefore it's not secure at all.

 It's model is basically, "in an ideal world where no one misuses
anything and does nothing wrong and there are no active adversaries
trying to subvert anything.." which is not particularly useful.

 Protocols that use a shared symmetric key/code/word/phrase as a
credential should be judged by the criteria set forth here:

Namely, "In a protocol we deem 'good' the adversary's chance to defeat
protocol goals will depend on how much she interacts with protocol
participants-- it won't significantly depend on her off-line computing
time." By that criteria, TLS-PSK is not good.



TLS mailing list