Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt

"Dan Harkins" <dharkins@lounge.org> Tue, 01 April 2014 22:30 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 DB8201A08EB for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 15:30:36 -0700 (PDT)
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 fcawgzonDkGI for <tls@ietfa.amsl.com>; Tue, 1 Apr 2014 15:30:35 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 160CA1A08DE for <tls@ietf.org>; Tue, 1 Apr 2014 15:30:35 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 645F0A888016; Tue, 1 Apr 2014 15:30:31 -0700 (PDT)
Received: from 24.120.218.98 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 1 Apr 2014 15:30:31 -0700 (PDT)
Message-ID: <c086306b2881a34c9f3823afbd0e72d3.squirrel@www.trepanning.net>
In-Reply-To: <20140401211637.GA21606@localhost>
References: <20140328195334.19328.19928.idtracker@ietfa.amsl.com> <CACsn0c==pRzDKd7G=eAhds=o9qexqe9Jb3DgNC9gzh-6xaKcAQ@mail.gmail.com> <dd67ab76dee19a82a0dfcdaa6512b905.squirrel@www.trepanning.net> <CACsn0ckQiNODB9DLj5XpcQDH2ykfD76CoV11-R4JJL+1_Vogfw@mail.gmail.com> <f8dc8cec46f6126146a7afa2421e43de.squirrel@www.trepanning.net> <CACsn0cmRRygPPk8=iU536-TK9mDFVcMOrYw_1tNV3=LZ02_9Hw@mail.gmail.com> <CAK3OfOjPyk2abEL-jqMk7ZujrF287yZnYJpr3xLs0yboFJX_6w@mail.gmail.com> <5db2aa46715b8f0b115b005b0abfbf58.squirrel@www.trepanning.net> <20140401211637.GA21606@localhost>
Date: Tue, 01 Apr 2014 15:30:31 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Nico Williams <nico@cryptonector.com>
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/NEExI7nUKqiSA-XDtxwdzrAWX2o
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt
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, 01 Apr 2014 22:30:37 -0000

On Tue, April 1, 2014 2:16 pm, Nico Williams wrote:
> On Tue, Apr 01, 2014 at 01:59:09PM -0700, Dan Harkins wrote:
>> On Tue, April 1, 2014 12:30 pm, Nico Williams wrote:
>> > On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd <watsonbladd@gmail.com>
>> > wrote:
>> >> PSK has no security? That's ridiculous: if high-entropy keys are used
>> >> it is fairly easy to see it is secure.
>> >
>> > TLS-PSK did not specify a PBKDF either, so it can't be used with
>> > passwords, therefore we might as well assume high-quality keys for
>> > TLS-PSK.  Therefore you're quite right.
>>
>>   There is nothing in the protocol that prevents it from being used with
>> passwords. You're not only assuming something about the nature of the
>> PSK, you're assuming something about the people that use the protocol
>> and that is quite naive.
>
> PSK requires pre-sharing the secret key.  If such presharing involves a
> password then the secret key must be derived from said password.  How?
> Well, the two peers have to agree.  How?  Well, it's not specified!

  No, the secret key IS the password, it's not derived from the password.

> If there interoperable TLS-PSK w/ password implementations, then there's
> a missing standard.  I have no knowledge of such implementations.
>
> Without any further input the only reasonable conclusion is that TLS-PSK
> does not support passwords.  Evidence to the contrary would be welcomed.

  Try openssl. It has an artificial hex checker for PSK inputs but make
your PSK be "bad" without the quotes. Works just fine.

  The presence of implementations is somewhat irrelevant since the point is
that the _specification_ allows for a PSK to be anything, it just needs to be
identical on both sides.

>>   Furthermore making assumptions about the nature of the PSK does not
>> change the fact that TLS-PSK has a defect: the advantage an attacker
>> gains is through computation and not interaction. And for the non-DHE
>> ciphersuites, that defect can be exploited through passive attack!
>
> Only if they are password-derived keys, otherwise no.

  No, that is wrong. Just because something is a number, or is taken
from a large space of numbers does not change the fact that the adversary
gains advantage through computation. It either passively observes a
single TLS-PSK exchange (if non-DHE) or it performs a single active attack
on a TLS-PSK user (if DHE) and then goes offline and crunches numbers
until it determines the PSK.

  Using a "high quality key" just makes that number crunching take more
time, it does not change the fundamental nature of the number crunching.
And therein lies the flaw of the TLS-PSK ciphersuites.

  A protocol that requires the adversary to gain advantage through
interaction and not through computation is vastly superior because
excessive unsuccessful interaction can be detected.

>> > Even if the server must store a password-equivalent I'd still want a
>> > decent PBKDF to be used for any protocol that derives keying material
>> > from passwords!
>>
>>   Why? Deterministically hashing a secret 1000 times or 4000 times
>> does not increase the entropy in the secret. A PBKDF is just supposed
>> to increase the work factor of the attacker, it does nothing to the
>> resulting keying material.
>
> Because verifier databases get compromised regularly.  Just point your
> browser to your favorite news site and wait a few weeks, you'll see.

  But that has nothing to do with how a protocol derives keying material.

>>   Wi-Fi specifies a PBKDF when using a PSK and the exchange is
>> essentially the same as the non-DHE TLS-PSK ciphersuites. That
>> protocol is horribly broken and tools exist on the Internet to attack
>> it. And guess what? People still use it with weak, low-entropy PSKs
>> in spite of assumptions to the contrary.
>
> My concern is not eavesdroppers in this case.  See above.

  So what? It's an example of a protocol that uses a PBKDF being
trivially and successfully attacked. The result of the attack is that
the PSK. If the attacker chooses to use that knowledge to further
eavesdrop it's up to him. Regardless of your concern, your belief in
the power of a PBKDF seems a bit misplaced.

  Dan.