Re: [TLS] PSK in 1.3?

[Watson Ladd <[e-mail]>]

On Oct 20, 2014 12:20 PM, "Dan Harkins" <[e-mail]> wrote:
>
>
> On Mon, October 20, 2014 11:06 am, Manuel Pégourié-Gonnard wrote:
> > On 20/10/2014 19:06, Dan Harkins wrote:
> >>   There is nothing to flesh out because you seem to not understand
> >> what a dictionary attack is-- but you're in company because neither
> >> did the editors of that RFC.
> >>
> >>   Protocols that use a static, symmetric credential like a PSK (or a
> >> password, the difference is semantic) are all flawed because the
> >> adversary is always assumed to have access to a pool from which
> >> the PSK (or password is drawn. Resistance against dictionary attack
> >> is then a demonstration that the advantage gained by the adversary
> >> is due to _interaction_ and not _computation_.
> >>
> >>   Merely making the pool from which the PSK is drawn, for instance
> >> by making it a bigger or including mixed case, etc, does not make
> >> the protocol resistant to dictionary attack.
> >
> > From a theoretical standpoint, the PSK key exchange is indeed vulnerable
> > to a
> > dictionary attack with this definition. In practice, if your keys are
> > 128-bit
> > long and chosen uniformly at random using a good source of entropy, I
> > doubt any
> > real-world adversary is able to gain a non-negligible advantage in the
> > foreseeable future.
>
>   The justification for these ciphersuites is some constrained device that
> has a small data and code size. But if you can not only generate 128-bit
> long uniformly random keys from a good source of entropy and also
> securely provision them on 2 (or more) devices then you don't need TLS.
> Just do static keyed symmetric crypto and you save even more data
> and code by eliminating TLS!
>
>   In practice, these things are deployed by people who probably do not
> read the RFC in question, are in a hurry, and don't understand the
> security implications of their use of TLS. The PSKs that get provisioned
> are the ones that are easy to enter with a low probability of error-- i.e.
> something considerably less than uniformly random 128-bit key
> generated from a good source of entropy.
>
>   This is not (only) a theoretical issue. It's practical reality.

I dissent here: interoperability and firewall traversal are good reasons
not to homebake something, and if this WG had done it's job, security would
likely be better then a home brewed protocol.
>
> > Also, it should be noted that with this definition, the TLS session keys
> > are
> > vulnerable to a dictionary attack too. In practice, it's not a problem
> > either
> > for the same reason. Obviously the difference between the pre-shared key
> > and the
> > TLS session keys is that the later is short-term while the former is
> > long-term.
> > Which basically boils down to the point that PSK lacks FS.
> >
> > Are you sure you have point besides:
> > - pre-shared key must be chosen with sufficient entropy and
> > - PSK does not offer FS?
>
>   Yes, I'm absolutely sure. It's:
>
>   - you can't ensure security with MUSTs and SHALLs; and,
>   - the use case that you say compels PSK ciphersuites actually argues
>      against you.
>
> TLS should be as misuse resistant as possible. That is, it should be as
> hard as possible to use improperly and that means no PSK ciphersuites.

I concurr.
>
>   regards,
>
>   Dan.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls