Re: [TLS] PSK in 1.3?

[Viktor Dukhovni <[e-mail]>]

On Mon, Feb 23, 2015 at 09:34:08AM -0800, Dan Harkins wrote:

> "Drawing from a database" is not user error. Every PSK is drawn from
> a database. You are just playing a semantic game by saying that if
> n is less than some arbitrary number (which you don't define) then it's
> a "dictionary" or "database" and if n is larger than some other arbitrary
> number (which you also don't define) then it's not.

Every AES-128 key is drawn from a database: [0, 2^128-1]
Every AES-256 key is drawn from a database: [0, 2^256-1]

>   No, it's not. If n=8 then the attack is trivial and succeeds almost
> instantaneously. If n=128 then with high probability a dictionary attack
> will not be successful. But in neither case is that "secure".

The PSK is secure once the search cost for the PSK exceeds the cost
of brute-forcing the key of the agreed TLS symmetric algorithm.

One time pads aside, there are no absolutely "secure" crypto-systems,
all practical cryptography assumes a resource-bounded adversary.
So a 128-bit (uniformly randomly chosen) PSK used to negotiate an
AES-128 key is "secure".

So the argument seems to boil down to whether TLS should banish a
key management approach that can be fragile in the hands of naive
users, but can in fact be used "securely" when practiced properly.

Whether misuse of PSK is particularly more likely than various
other lapses (say unwitting deployment of MiTM root CAs) is not
obvious.  Far too few products get the security scrutiny they
deserve.

Device vendors will always find a way to ship gear with weak factory
security settings, whether PAKE, PSK, SSH keys, stock RSA keys, ...

I am very much sympathetic to the advantages of PAKE over PSK when
one of the key stores is a human brain, or people are involved in
the process of generating and distributing the shared secrets.  I
am not sure that this is sufficient grounds to rule out PSK, or
that doing so substantially addresses poor key management practices.

-- 
	Viktor.