Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

"Dan Harkins" <dharkins@lounge.org> Sat, 07 December 2013 23:21 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 63BF21AE454 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 15:21:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.567
X-Spam-Level:
X-Spam-Status: No, score=-3.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, 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 8tCs4eXNvUSw for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 15:21:05 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E3E491AE44F for <tls@ietf.org>; Sat, 7 Dec 2013 15:21:04 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id F17B11022404C; Sat, 7 Dec 2013 15:20:59 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 7 Dec 2013 15:21:00 -0800 (PST)
Message-ID: <499f3256234d13c6522a250bfd9371d9.squirrel@www.trepanning.net>
In-Reply-To: <52A32080.3090601@elzevir.fr>
References: <CACaGApmwcaZuicbdk8zC7K+KPa4=Rav95GJU3t4ALLq3ENwVeg@mail.gmail.com> <6f16d6d556c68a58918423e0419d31eb.squirrel@www.trepanning.net> <52A32080.3090601@elzevir.fr>
Date: Sat, 7 Dec 2013 15:21:00 -0800 (PST)
From: "Dan Harkins" <dharkins@lounge.org>
To: Manuel =?iso-8859-1?Q?P=E9gouri=E9-Gonnard?= <mpg@elzevir.fr>
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
Cc: tls@ietf.org
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
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: Sat, 07 Dec 2013 23:21:06 -0000

On Sat, December 7, 2013 5:20 am, Manuel Pégourié-Gonnard wrote:
> On 07/12/2013 00:38, Dan Harkins wrote:
>>   It's a balanced PAKE protocol. Like all such schemes (e.g EKE, J-PAKE)
>> the database of passwords is presumed to not be available to the
>> attacker.
>>
> It's not supposed to be available to the attacker, but as CodesInChaos
> pointed
> out, in real life it has an annoying tentency to become available to
> attackers
> much more often than one would like. Anyway, why do you hash & salt the
> paswords
> in the first place, if not to offer some protection in case the database
> becomes
> available to an attacker?

  Originally the passwords were not salted but I received a comment
recommending that it be done.

> HMAC-SHA256 is a very poor protection, and weak protections are kind of
> worse
> than no protection at all: they give an illusion of security.

  I'm assuming you don't know of an efficient pre-image attack.
So I will assume you're referring to the ability of someone to do
a dictionary attack given the database of salted passwords. And in
that case, yes, this is not that big protection. Modular exponentiation
(used by augmented PAKE schemes) is not much better either. And
given the coWPAtty (and family) attacks against WPA-PSK that uses
PBKDF2 with 4096 iterations of HMAC-SHA1 I would say that's not
too good either.

  So when an attacker has a database of protected passwords you
should assume the worst regardless of how you protect the
passwords.

  Let me point out yet again that this draft is not proposing a general
purpose cipher suite that is appropriate for all situations. If it is not
appropriate for your TLS deployment then by all means don't use it.
But just because it is not appropriate for your particular deployment
does not mean it is not appropriate for anyone.

  regards,

  Dan.