Re: [TLS] PSK in 1.3?

["Dan Harkins" <[e-mail]>]

  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 <[e-mail]>:
>>>
>>>>
>>>> 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
>>>
>>> http://eprint.iacr.org/2014/037
>>>
>>> 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
cannot.

> 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:
>>
>> http://www.iacr.org/archive/eurocrypt2000/1807/18070140-new.pdf
>>
>> 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.
>
> ...no, 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
cipher
suite and you'd be none the wiser-- plumb the key, hey it works!

  regards,

  Dan.