Re: [TLS] PSK in 1.3?

Stephen Checkoway <> Tue, 24 February 2015 03:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 72CE11A0072 for <>; Mon, 23 Feb 2015 19:08:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E_D7NeHybask for <>; Mon, 23 Feb 2015 19:08:20 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8A8C11A001C for <>; Mon, 23 Feb 2015 19:08:20 -0800 (PST)
Received: by qcwb13 with SMTP id b13so14674371qcw.7 for <>; Mon, 23 Feb 2015 19:08:19 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=LHPHqaKQ+dQ2f5y2GB6RGvPko1MhlH8qshq2IRRm2zw=; b=ctD5dZ1aoWvrBavMM+c33wAykzjOUA2tD8fOTL8tqy/7Vp9YPPRxdPTlVLor64P1jq 8CUl5sQ7DMmBVLWOxxEE/DnQc2OpplVIvU+auipqHf/v37DPCVKkju46LomSYlyPEVm7 j9eLlS720WRAjsFCjPrKhRiZFp8A5j4IzM+WzFBy4BHdktT8tlRUA1Zy1K3LtILcH27g l7pRwGF1Wsc1qt5fOnl+O5N5eXJY/ODaCWmS2DmhKenza3x1SI9qeu2IQcT1OVCvI1as krMVRo8oZreqDTGZtJjtgNMU3y2cpn3UOpstroz0tS/MQZ4Xy9NUwUwx2hjJ8ZAe18rZ 2dpA==
X-Gm-Message-State: ALoCoQlRwtYTKrG68dyZmFMnYrQCHXOKHPXeI1Ut9pu19di2JNcLS8KBlnP4C/B0CaAWXDpjxliZ
X-Received: by with SMTP id dk3mr32531519qcb.30.1424747299775; Mon, 23 Feb 2015 19:08:19 -0800 (PST)
Received: from ( []) by with ESMTPSA id t51sm3573649qge.28.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 19:08:18 -0800 (PST)
Received: from [] (hackintosh.local []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 0A04CAC287E; Mon, 23 Feb 2015 22:08:17 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="windows-1252"
From: Stephen Checkoway <>
X-Priority: 3 (Normal)
In-Reply-To: <>
Date: Mon, 23 Feb 2015 22:08:16 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <mc9gjp$7nv$> <> <> <> <> <>
To: Dan Harkins <>
X-Mailer: Apple Mail (2.1878.6)
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: Tue, 24 Feb 2015 03:08:22 -0000

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.

>> 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