Re: [TLS] PSK in 1.3?

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

  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. It's saying that if only the
client
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:

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.

  regards,

  Dan.