Re: [TLS] PSK in 1.3?

"Dan Harkins" <dharkins@lounge.org> Tue, 21 October 2014 18:45 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 4BDA61A8775 for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 11:45:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.968
X-Spam-Level:
X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 ib74_nZYfP2F for <tls@ietfa.amsl.com>; Tue, 21 Oct 2014 11:45:49 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id D499D1A8761 for <tls@ietf.org>; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 6511610224008; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 21 Oct 2014 11:45:48 -0700 (PDT)
Message-ID: <3653ffe169c72f3302d605a4bc24bb0d.squirrel@www.trepanning.net>
In-Reply-To: <20141021160247.GP19158@mournblade.imrryr.org>
References: <9A043F3CF02CD34C8E74AC1594475C739B9D3EAE@uxcn10-5.UoA.auckland.ac.nz> <96b88d73f776e16e3f5487643fb59a31.squirrel@www.trepanning.net> <20141021160247.GP19158@mournblade.imrryr.org>
Date: Tue, 21 Oct 2014 11:45:48 -0700
From: Dan Harkins <dharkins@lounge.org>
To: tls@ietf.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/LMIDjPTAFGADjBPPN_55DBMIFRA
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, 21 Oct 2014 18:45:51 -0000

On Tue, October 21, 2014 9:02 am, Viktor Dukhovni wrote:
> On Mon, Oct 20, 2014 at 01:34:38PM -0700, Dan Harkins wrote:
>
>> The ciphersuites are _completely oblivious_
>> to the type and quality of the credential they use. You can't claim the
>> _protocol_ is resistent to dictionary attack if the protocol can be used
>> in a manner that makes it susceptible to dictionary attack.
>
> No protocol is resistant to dictionary attack under the above
> definition.

  The point is that increasing the size of the PSK does not make the
_protocol_ resistant to dictionary attack. It just makes the attack
harder to successfully conclude.

  This is not my definition by the way. But instead of paraphrasing, let
me quote from "Authenticated Key Exchange Secure Against Dictionary
Attacks" by Bellare, Pointcheval, and Rogaway:

        "A theorem asserting security of some protocol make qualitative
         how much _computation_ helps and just how much _interaction_
         does. One sees whether or not one has security against dictionary
         attacks by looking to see if maximal adversarial advantage grows
         primarily with the ratio of interaction to the size of the password
         space."

Increasing the size of the PSK just makes the "password space" larger
but that has no effect on interaction. With the TLS PSK ciphersuites,
there's one interaction and then there's a whole bunch of computation.
Increasing the amount of computation necessary doesn't make the
protocol resistant to dictionary attack because there's still just one
interaction-- the adversarial advantage does not grow primarily with
the ratio of interaction to the size of the search space.

  And there are protocols that are resistant to dictionary attack under
that definition. There's one in the paper. Or look at your favorite PAKE.

  Dan.