Re: [TLS] PSK in 1.3?

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

  Hi John,

On Mon, February 23, 2015 6:55 am, John Mattsson wrote:
> 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.

  There is no confusion (at least on my part). I think the confusion is that
you think that merely by naming ("this is a password", "this is a PSK") the
credential used you can make "a perfectly fine cipher suite."

  A dictionary attack is one in which the advantage gained by the adversary
is a function of computation and not interaction. It says nothing about the
size, or make up, of the pool from which the shared credential was drawn.
A good PRNG just ensures that each credential in the pool has an equally
good chance of being chosen. If the protocol you use the shared credential
with is susceptible to an attack whose success depends on computation
and not interaction with protocol participants than it's susceptible to a
dictionary attack.

  Now, granted, a pool that consisted of words from Webster's starting
with the letter "a" would be much smaller than a pool consisting of numbers
between 0 and 2^128 and a dictionary attack against the former would,
with high probability, return success faster than a dictionary attack against
the latter but the attack is identical.

  Increasing the size of the pool from which the credential was drawn
makes a dictionary attack take longer (and possibly prohibitively so) but
it doesn't magically make the protocol somehow resistant to dictionary
attack.

> Non-PSF PSK has the same weaknesses as Non-PSF RSA. I think the
> authentication and key agreement discussions should be separated.

  Key establishment and authentication go hand-in-hand. They have
to.

  And the issue is not key establishment versus authentication, it's
misuse resistance. PSKs are not misuse resistant, PAKEs are. And that
is because, regardless of the size of the pool from which the shared
credential was drawn, a dictionary attack (as defined above) is not
possible.

  Dan.

> /John
>
> On 21 Feb 2015, at 09:03, Dan Harkins
> <[e-mail]<mailto:[e-mail]>> 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]<mailto:[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.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>