Re: [TLS] PSK in 1.3?

Hi,
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.
/John

On 21 Feb 2015, at 09:03, Dan Harkins <dharkins@lounge.org<mailto:dharkins@lounge.org>> 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 <dharkins@lounge.org<mailto:dharkins@lounge.org>>:

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.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls