Re: [TLS] PSK in 1.3?

Viktor Dukhovni <> Mon, 23 February 2015 19:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A1E2F1A3BA0 for <>; Mon, 23 Feb 2015 11:16:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id m3x6uZ696XvK for <>; Mon, 23 Feb 2015 11:16:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 295391A6EDA for <>; Mon, 23 Feb 2015 11:16:07 -0800 (PST)
Received: by (Postfix, from userid 1034) id 231A6282F52; Mon, 23 Feb 2015 19:16:06 +0000 (UTC)
Date: Mon, 23 Feb 2015 19:16:06 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <> <> <> <> <> <mc9gjp$7nv$> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] PSK in 1.3?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Feb 2015 19:16:11 -0000

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

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.