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

"Dan Harkins" <dharkins@lounge.org> Tue, 03 December 2013 08:27 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 2B4B31AE022 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 00:27:45 -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 1nfV89ueQH25 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 00:27:43 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 53BE81ADFFF for <tls@ietf.org>; Tue, 3 Dec 2013 00:27:43 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 4A2B210224008; Tue, 3 Dec 2013 00:27:40 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 00:27:40 -0800 (PST)
Message-ID: <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net>
In-Reply-To: <529C990D.3020608@gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com>
Date: Tue, 03 Dec 2013 00:27:40 -0800
From: Dan Harkins <dharkins@lounge.org>
To: Rene Struik <rstruik.ext@gmail.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
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: Tue, 03 Dec 2013 08:27:45 -0000

  Dear Rene,

On Mon, December 2, 2013 6:28 am, Rene Struik wrote:
> Dear colleagues:
>
> I had a look at draft-ietf-tls-pwd-02. While I do appreciate the work
> that went into this draft, I have to concur with some other commenters
> (e.g., Doug Stebila, Bodo Moeller) that it is unclear what makes this
> protocol special compared to other contenders, both in terms of
> performance and detailed cryptanalysis. One glaring omission is detailed
> security evidence, which is currently lacking (cross-referencing some
> other standards that have specified the protocol does not by itself
> imply the protocol is therefore secure). I am kind of curious what
> technical advantages the "Dragonfly" protocol has over protocols that
> seem to have efficiency, detailed and crypto community reviewed
> evidence, such as, e.g., AugPAKE (which is another TLS-aimed draft) and
> others. So, if the TLS WG has considered a feature comparison, that
> would be good to share.

  dragonfly is a balanced PAKE kind of exchange and it has certain
advantages over augmented PAKE schemes like TLS-SRP (which, unlike
the augPAKE draft, is a published RFC that has been implemented).
Namely, the domain parameter set is not fixed with the password and
can be negotiated to provide security commensurate with that offered
by the rest of the cipher suite. And yes, the drawback of a balanced
PAKE scheme is that if the server is compromised and the password
file exposed then an attacker can impersonate users (although, in my
opinion, that is something of a dubious benefit since the server is
already compromised and this will be the least of your problems).

  This has already been discussed in this thread by the way.

> I would recommend to ask CFRG to carefully review the corresponding
> irtf-dragonfly-02 document (to my knowledge, there has been no LC and it
> is still a draft document there) and align the TLS document
> draft-ietf-tls-pwd-02 document with whatever comes out of that effort
> (currently, there are some security-relevant differences). This time
> window could also be used for firming up security rationale, thus
> aleviating concerns on that front.

  This suggestion has already been done.

> Two final comments:
> a) It is unclear why one should hard code in the draft that elliptic
> curves with co-factor h>1 would be ruled out. After all, this would make
> it much harder to extend the reach of the draft to prime curves with
> co-factor larger than one and to binary curves.

  You're right, it does prevent the use of binary curves and prime curves
with a co-factor greater than one. That's the whole point. The motivation
is to avoid walking through a patent mine field.

> b) The probabilistic nature of the "hunting and pecking" procedure may
> be a recipe for triggering implementation attacks. Wouldn't one be much
> better off removing dependency on non-deterministic password-to-point
> mappings (e.g., AugPAKE, Icart map, German BSI-password protocol)?

  The "hunting and pecking" procedure is deterministic otherwise there
would be no guarantee that each side arrived at the same element
given the same input.

  regards,

  Dan.

> Best regards, Rene
>
> On 11/7/2013 8:11 PM, Joseph Salowey (jsalowey) wrote:
>> This is the beginning of the working group last call for
>> draft-ietf-tls-pwd-01.   The underlying cryptographic protocol for
>> TLS-PWD has been reviewed by the IRTF CFRG group with satisfactory
>> results.  The document needs particular attention paid to the
>> integration of this mechanism into the TLS protocol.   Please send
>> comments to the TLS list by December 2, 2013.
>>
>> - Joe
>> (For the TLS chairs)
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>