Re: [TLS] PSK in 1.3?

"Dan Harkins" <> Mon, 23 February 2015 17:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E50DA1A1B7F for <>; Mon, 23 Feb 2015 09:34:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tpWV64ktyoxL for <>; Mon, 23 Feb 2015 09:34:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D8A8D1A1BCB for <>; Mon, 23 Feb 2015 09:34:08 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 3E8BB10224008; Mon, 23 Feb 2015 09:34:08 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Mon, 23 Feb 2015 09:34:08 -0800 (PST)
Message-ID: <>
In-Reply-To: <mc9gjp$7nv$>
References: <> <> <> <> <> <> <> <mc9gjp$7nv$>
Date: Mon, 23 Feb 2015 09:34:08 -0800
From: Dan Harkins <>
To: Alex Elsayed <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <>
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 17:34:12 -0000

  Hi Alex,

On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote:
> 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
>>>> for
>>>> > it. But the standards don’t say that. They
>>>> don’t say
>>>> that PSK
>>>> > ciphersuites are especially for constrained devices. So if we insist
>>>> that
>>>> > 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
>>>> session.
>>>>   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
>>>> the
>>>> issue is not just PFS (or the lack of it), it's that PSK ciphersuites
>>>> are
>>>> susceptible to dictionary attack.
>>>> > So either we believe that PSK compromise is unlikely, or we believe
>>>> that
>>>> > the data in a connection with a PSK ciphersuite is not
>>>> future-sensitive.
>>>> > 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
>>>> belief.
>>>> 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
>>> useful.
>>   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.
> Sure, if they draw them from a database. Which would be about as stupid as
> choosing an RSA key from the Debian weak-keys bug, or doing ECDSA
> signatures
> with the same nonce every time, or similar boneheaded maneuvers that
> invalidate the protocol guarantees.
> It's not the "pre-shared password" protocol, or even "pre-shared
> passphrase." It's "pre-shared key," and as such it should be used with a
> _proper key_ - that is to say, a string chosen uniformly at random from
> {0,1}^n where 'n' is the key size.

  Then your "database" is all numbers between 0 and 2^n. And you
randomly draw from that database.

>> It's saying that if only the client and server know the PSK then the
>> resulting secret will be known only to them too
> Yes. That is the guarantee the protocol gives.
>> 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.
> But this is specious, because it's just as true of any number of other
> protocols - ECDSA's nonces being a particularly notable example. Reuse
> them,
> and you're leaking key bits like a firehose full of porcupines. Sony
> learned
> that the hard way.

  Yes, ECDSA has a misuse-resistance problem. Happily, that can be
hidden from "Joe Random, user of TLS" in a fashion that the PSK problem

> Sure, I think easily-misused APIs are better avoided - but I also feel you
> are drastically overstating your case, and weakening it by doing so. When
> faced with people having said multiple times that 'drawing from a
> database'
> is user error and an invalid use of the protocol, it comes across as
> either
> obtuse or intellectually dishonest - neither of which I believe you are.

  Thanks. But by equating misuse resistance problems with a PSK with
misuse resistance problems with ECDSA you are "drastically overstating
your case and weakening it by doing so".

  "Drawing from a database" is not user error. Every PSK is drawn from
a database. You are just playing a semantic game by saying that if
n is less than some arbitrary number (which you don't define) then it's
a "dictionary" or "database" and if n is larger than some other arbitrary
number (which you also don't define) then it's not.

>> And therefore it's not secure at all.
> Then we really ought to stop using ECDSA... pretty much anywhere, since
> its
> nonces require much the same care.

  Uhm, no. The nonce in ECDSA needs to be unique per signature. The
user has no ability to influence this in a general purpose TLS library.
Whereas the PSK has to be plumbed, by the user, into the TLS library,
thereby opening up the misuse resistance can.

>>   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.
> No, its model is "For shared keys drawn uniformly from {0,1}^n, this is
> secure".

  No, it's not. If n=8 then the attack is trivial and succeeds almost
instantaneously. If n=128 then with high probability a dictionary attack
will not be successful. But in neither case is that "secure".

> Active adversaries have nothing to do with it, so long as the user fulfils
> their side of the API contract.

  Active adversaries are the ones launching the attack. They have very
much to do with it!

>>   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.
>, if the user isn't screwing up in much the same kind of way as would
> lead them to horrific misuse of ECDSA, TLS-PSK is just fine.
> I'm not saying PSK is ideal - it's patently not. A misuse-resistant
> protocol
> *that meets the needs of the people using PSK* would be wonderful to have.

  And those needs are what? Plumbing the PSK into TLS via some API call or
some UI. Which can be easily handled by a misuse-resistant PAKE. In fact,
the change from PSK cipher suite to PAKE cipher suite would not be apparent
from the point-of-view of "the needs of people using PSK."

> But claiming it's worse than it is just makes people who see it as their
> only option feel more pressed to defend it, rather than actually helping
> to
> move the discussion forward on finding a viable alternative.

  A viable alternative is TLS-SRP. Or TLS-pwd. Since there is no augmentation
involved in the latter, it could be swapped in place of your favorite PSK
suite and you'd be none the wiser-- plumb the key, hey it works!