Re: [TLS] PSK in 1.3?

"Dan Harkins" <dharkins@lounge.org> Tue, 24 February 2015 02:33 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DE61A1B8C for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 18:33:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1NnDdCq5kKb for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 18:33:31 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7A87B1A1B8A for <tls@ietf.org>; Mon, 23 Feb 2015 18:33:31 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id B0F771FE01F0; Mon, 23 Feb 2015 18:33:30 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 23 Feb 2015 18:33:30 -0800 (PST)
Message-ID: <3ce50aefd478490a025d7ff9942d6bf0.squirrel@www.trepanning.net>
In-Reply-To: <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org>
References: <544384C7.9030002@polarssl.org> <78795A6D-3DFA-41C6-A380-C63DDF4C0285@gmail.com> <5443BF11.3090505@polarssl.org> <1D875BD8-2727-4895-842A-FC4FAA482E15@gmail.com> <5e587b4474939cad09c12cbf3625dd98.squirrel@www.trepanning.net> <CAO9bm2mQzjiLpMgB-mh-bRca-A2gkTZiBd9c3CsFq4kekBGxUw@mail.gmail.com> <07df9eeefbc1738ea645d72d0afb35b5.squirrel@www.trepanning.net> <mc9gjp$7nv$1@ger.gmane.org> <5f40f09f6b0268a455f281297c971708.squirrel@www.trepanning.net> <AA125A16-FD73-42C2-B196-89FFC6E9ED92@pahtak.org> <ab84dca54551eee2f845f6fb0274d6c1.squirrel@www.trepanning.net> <62A56053-48BD-44E2-838F-2B5FAA709274@pahtak.org>
Date: Mon, 23 Feb 2015 18:33:30 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Stephen Checkoway <s@pahtak.org>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/4Gxk6vC12sDMcVWc8SnnfIMAVOo>
Cc: tls@ietf.org
Subject: Re: [TLS] PSK in 1.3?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Feb 2015 02:33:33 -0000


On Mon, February 23, 2015 5:15 pm, Stephen Checkoway wrote:
>
> On Feb 23, 2015, at 7:06 PM, Dan Harkins <dharkins@lounge.org> wrote:
>
>>
>> On Mon, February 23, 2015 12:55 pm, Stephen Checkoway wrote:
>>>
>>> On Feb 23, 2015, at 12:34 PM, Dan Harkins <dharkins@lounge.org> wrote:
>>>
>>>> On Sat, February 21, 2015 12:45 am, Alex Elsayed wrote:
>>>>> No, its model is "For shared keys drawn uniformly from {0,1}^n, this
>>>>> is
>>>>> secure".
>>>>
>>>> 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".
>>>
>>> What is your definition of secure then?
>>
>>  I meant _the protocol_ is not secure in either case. The protocol
>> doesn't
>> magically become secure because it gets used differently. I gave a
>> definition in this thread already.
>
> I must be missing something here. You're saying that since an adversary
> can, in theory, enumerate 2^n possible pre-shared keys for any n, the
> protocol is insecure.

  I'm saying that since the security of the protocol depends on it being
used right, _the protocol_ cannot be said to be secure.

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

  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.

 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.

  Dan.