Re: [TLS] PSK in 1.3?

[Alex Elsayed <[e-mail]>]

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.

> 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.

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.

> 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.

>   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".

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

>   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.

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.

>   regards,
> 
>   Dan.