Re: [TLS] PSK in 1.3?

Watson Ladd <> Tue, 24 February 2015 05:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3DFA41A1ADB for <>; Mon, 23 Feb 2015 21:36:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_31=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W-B3XRYyo52p for <>; Mon, 23 Feb 2015 21:36:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46E1D1A0089 for <>; Mon, 23 Feb 2015 21:36:54 -0800 (PST)
Received: by ykp9 with SMTP id 9so1614250ykp.5 for <>; Mon, 23 Feb 2015 21:36:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=WTHfttKymmQWSlEB1iEubLS0zVQbtJrXQoz6uYiTXMo=; b=q8Sz8LjNTTxKh1BcmVJnob/SOrK9N5chlY27ruqek4PLygv7qWPPWFXg16a+QLdksV dCNO2vHv9OdPqgZHd53+HQp4Vn5V0bGZilay6EGazKTxv1d7t6eDMJY1MVoul51GOsKs 9++8wh9uKO4QCiUP7one+eTyd7qYD1Uvg666dH8NZkkQIlQpeyosOxBAUD6V9hb0VvOm Gi5dTgub077N6r0zNAWIYvaYj3OO6NPqhPZNh2hc5/JWkS9ADnGhhHM9n5ZmHgndA09r vheO6ofKEPYIRWvZCEQwLRjUucGZNfJWB4ZT+V1XMmuhivR/m0LtMRVkOwHPlcw6+OeU +HMA==
MIME-Version: 1.0
X-Received: by with SMTP id s1mr9115169yho.49.1424756213506; Mon, 23 Feb 2015 21:36:53 -0800 (PST)
Received: by with HTTP; Mon, 23 Feb 2015 21:36:53 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <mc9gjp$7nv$> <> <> <> <> <> <>
Date: Mon, 23 Feb 2015 21:36:53 -0800
Message-ID: <>
From: Watson Ladd <>
To: Stephen Checkoway <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Cc: "" <>
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: Tue, 24 Feb 2015 05:36:56 -0000

On Mon, Feb 23, 2015 at 7:08 PM, Stephen Checkoway <> wrote:
> On Feb 23, 2015, at 9:33 PM, Dan Harkins <> wrote:
>> I'm saying that since the security of the protocol depends on it being
>> used right, _the protocol_ cannot be said to be secure.
> Every security protocol's security depends on it being used correctly. That doesn't seem like a useful metric here.

As far as I can tell, neither of you actually are arguing about what
you're actually arguing about. The question isn't whether PSK mode
satisfies the Bellare-Pointcheval-Rogaway definitions. Instead, it's
about using in TLS 1.3 vs replacing it with a mode that uses a PAKE
instead. The stated argument is that PSK is getting deployed with
passwords instead of keys in many places: that's completely orthogonal
to the discussion that's been taking place.

As far as how much PAKEs cost, SPAKE2 is 2.5 exponentiations per side.
Elligator is 2, but slightly harder to implement. On 32-bit arm
processors I think these exponentiations cost around 2 million cycles
according to SUPERCOP.  So not a completely trivial cost, but most
processors will do better, and I think the measurement was borked due
to compiler issues.

(Elligator might even be possible on genus 2: let me think about that
for a while. Certainly on hyper-and-elliptic. )

Watson Ladd

>>> I don't see how to square that with Bellare-Pointcheval-Rogaway's
>>> definitions (which I think is what you're using as your definition of
>>> security). You write,
>>>> 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.
>>> But that seems to misunderstand the quoted sentence. It's the adversaries
>>> chance to defeat the protocol goals which is deemed to be good, not the
>>> protocol itself. More to the point, the security of a protocol is defined
>>> in terms of an adversary running in time t and making q queries. If the
>>> passwords are drawn from a space of size N, then the fact that an
>>> adversary which runs in time N or makes N queries can have advantage 1
>>> doesn't really tell us anything. See, for example, Theorem 1 of the BPR
>>> paper. If q_se = N, then the advantage is bounded by 1, but of course it
>>> is. That doesn't make the protocol under consideration insecure due to
>>> dictionary attacks. Indeed, see remark 9 just below noting that making N
>>> larger makes dictionary attacks moot.
>>  No, I don't think you understand the quoted sentence.  Note how they say,
>> "In a protocol we deem 'good'…" That right there means they're talking about
>> the protocol being good or not, and not the adversary's chance to defeat
>> protocol goals.
> You may be right. I was mentally inserting a comma after "in a protocol" whereas you are inserting one after "good." But my reading doesn't fit with the rest of the sentence. My mistake.
>> The adversary's chance of defeating protocol goals will grow
>> (by exploiting the flaw in all protocols that authenticate using a symmetric
>> key/code/word/phrase), it's a matter of how.
> I don't think this is a matter of using a symmetric key/code/word/phrase at all. You have exactly the same problem using DHE. I can enumerate (in theory) the space of secret keys until I find one with a corresponding public key that appears in the TLS handshake. Now I've recovered the shared secret and I've done it with zero interaction with the protocol, purely offline computation.
>> The _protocol_ is deemed
>> "good" if the adversary's advantage grows as a function of computing, not
>> as a function of interaction with protocol participants.
> Wait, now you're saying something different. Before, you were saying that the advantage should grow as a function of interactions and quoted "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." But of course, it depends on both computation (time) and interactions and both are captured in the formal definitions given in the paper.
>>  As Remark 8 notes, "The resistance to dictionary attacks is captured
>> by the first term which is the number of send queries divided by the size
>> of the password space." Making q_se = N means that the number of
>> interactions is equal to the size of the password space and that does
>> not capture resistance to dictionary attack.
> In your brute force attack, you're either making N connections to the server or you're watching a connection passively and computing N possible master secrets and seeing which enable to you decrypt. Either takes time at least N and both are captured in the notion of advantage. So if Adv(t,q) is the maximum advantage of an adversary running in time t, making q queries (similar to the definition of Adv_G^{dh} on page 149), we have either Adv(N,N) = 1 or Adv(N,0) = 1. Neither result is particularly meaningful and certainly doesn't tell us that TLS-PSK is insecure.
>> It is obvious that a making n large enough can make a dictionary attack
>> moot. I have not said otherwise. It just doesn't make _the protocol_
>> resistant to dictionary attack.
> This isn't a useful distinction then since no mode of TLS is resistant to dictionary attacks by what I take to be your definition.
> --
> Stephen Checkoway
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin