Re: [TLS] PSK in 1.3?

Stephen Checkoway <s@pahtak.org> Tue, 24 February 2015 01:15 UTC

Return-Path: <s@pahtak.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 2A56B1A033A for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 17:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_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 NhlgwdcZh8Lm for <tls@ietfa.amsl.com>; Mon, 23 Feb 2015 17:15:49 -0800 (PST)
Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84341A00CA for <tls@ietf.org>; Mon, 23 Feb 2015 17:15:49 -0800 (PST)
Received: by qcvp6 with SMTP id p6so14270347qcv.12 for <tls@ietf.org>; Mon, 23 Feb 2015 17:15:48 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=xNUViBDQ6ePSOGTriLGsUwwzWgCIvwAK8vFDuJ1Qdrg=; b=hDdZWP08ItW3V39RYpQXYBAZrlfD5Pr/Zu45A9RfVBnxHNYyIacM4dr/8odvGanEXk G4s3kVTpQwguAaQZDafwGB7FquytEhzTcAeWGrdDqtdarDc1Hk8NwxYgdUlr4uIHZ87C B90AAhbzodzueQlQK0Cb+joDxfGsMVsDby3iDHSfLV1GMTMdFK+d2QP21UsimQCWzxJO aSMDOqIzALj20FkQZwFvoxPDYv+0AILiu/2PNT74wio2JhjVmwMSEzk1fKQTfTPWbeq1 K9qANVvIuFSGabC9lb5U2ts7B3e0Q6+wdDBWy3wTklYQrW5w/fKacBra6ZBEYKfohIN/ x3mA==
X-Gm-Message-State: ALoCoQnAAH7FI77uz71UQfsmOgCBNI+xybc5XwLbGz9bgA6jz2PkBU5mQu9lV0seVLM1286rwqvL
X-Received: by 10.140.232.6 with SMTP id d6mr30727926qhc.99.1424740548673; Mon, 23 Feb 2015 17:15:48 -0800 (PST)
Received: from zbox.pahtak.org (c-73-213-90-80.hsd1.md.comcast.net. [73.213.90.80]) by mx.google.com with ESMTPSA id q5sm11031158qai.47.2015.02.23.17.15.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Feb 2015 17:15:47 -0800 (PST)
Received: from [192.168.1.7] (hackintosh.local [192.168.1.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id 02496AC287E; Mon, 23 Feb 2015 20:15:43 -0500 (EST)
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Content-Type: text/plain; charset="iso-8859-1"
From: Stephen Checkoway <s@pahtak.org>
X-Priority: 3 (Normal)
In-Reply-To: <ab84dca54551eee2f845f6fb0274d6c1.squirrel@www.trepanning.net>
Date: Mon, 23 Feb 2015 20:15:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <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>
To: Dan Harkins <dharkins@lounge.org>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/1mVBmEm0vVnO0APKNj5L2uGgbYM>
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 01:15:51 -0000

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

-- 
Stephen Checkoway