Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
Mohamad Badra <mbadra@gmail.com> Tue, 03 December 2013 18:25 UTC
Return-Path: <mbadra@gmail.com>
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 025C91AD944 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 10:25:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Level:
X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 2zpDZzv6B0Fl for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 10:25:17 -0800 (PST)
Received: from mail-ve0-x233.google.com (mail-ve0-x233.google.com [IPv6:2607:f8b0:400c:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id A92C01AE16F for <tls@ietf.org>; Tue, 3 Dec 2013 10:25:16 -0800 (PST)
Received: by mail-ve0-f179.google.com with SMTP id jw12so10516705veb.24 for <tls@ietf.org>; Tue, 03 Dec 2013 10:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tsFmAh+CCvHGzw4jYNnkcZh/K+FHTxDuZOLs9kdYx4g=; b=xwE5vuZQmL2oPwUBusIPAxkWJ4yssie0IBzRgd0HJG1njWQFmaTr7KlYrN6Z5eQ7Aq 15r6fpGIN1QmiaBzq5/TfBUlx1Yem+0OBJGhTbdPxxtIIK3EIObqjLXWL5x+i6pCsX9V PTd470kYiIhOFnYFqrf62mi4jAl2vB+JIk2tZTIIxU6iwq6l59D2E1ddHt/4lBxsUWyl DWXkaCG0fdAOaRnICreF2Q4tyt4GPqQD1pFZJv/A3rOow2Sts1882OiJVFQ93XAKrL8C JNH4T24qFvZXLMiLs4/Ic/5dHMCwxZu5aFMRd+KYnctB55W6RGFROXIOWa5dESfciaq+ FUjg==
MIME-Version: 1.0
X-Received: by 10.220.50.18 with SMTP id x18mr106068vcf.29.1386095113479; Tue, 03 Dec 2013 10:25:13 -0800 (PST)
Received: by 10.221.43.138 with HTTP; Tue, 3 Dec 2013 10:25:13 -0800 (PST)
In-Reply-To: <CACsn0c=PnB2CA8rpNtcOp6RRLNWHEPN-aN+AdWSF7FJM2wZOog@mail.gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <CACsn0cmtP_dF7N2op4DZUwR8t-fW30GmtdqQoteZ+9Y0oH3dUg@mail.gmail.com> <a4b1729af4966e99df1582943f02a0a8.squirrel@www.trepanning.net> <CACsn0cksrU2GErd6FkZPkXKXK4pSJhTbBoJ-0C-14jsM=UY2iQ@mail.gmail.com> <14e67efee74d2ec6d535f6750ed829db.squirrel@www.trepanning.net> <CACsn0c=PnB2CA8rpNtcOp6RRLNWHEPN-aN+AdWSF7FJM2wZOog@mail.gmail.com>
Date: Tue, 03 Dec 2013 22:25:13 +0400
Message-ID: <CAOhHAXw5Px1mB9ogtniBHwLknTT6F0db4=gEOr+RcXxf2bCQ_A@mail.gmail.com>
From: Mohamad Badra <mbadra@gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b34427add798704eca56aea"
Cc: "tls@ietf.org" <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 18:25:22 -0000
For info, I submitted during 2007 and 2008 two documents to enable authentication using passwords. http://tools.ietf.org/id/draft-badra-tls-password-ext-01.txt ftp://ftp.kfki.hu/pub/documents/iana/drafts/draft-badra-tls-password-00.txt Both of them are simple, and secure enough to enable password-based authentication Best regards, Badra On Tue, Dec 3, 2013 at 10:08 PM, Watson Ladd <watsonbladd@gmail.com> wrote: > On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins <dharkins@lounge.org> wrote: > > > > On Tue, December 3, 2013 8:12 am, Watson Ladd wrote: > >> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins <dharkins@lounge.org> > wrote: > >>> > >>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote: > >>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <rstruik.ext@gmail.com> > >>>> 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. > >>>>> > >>>>> 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. > >>>> I do not like the way this standard mixes algorithmic details with > >>>> instantiation > >>>> details. It makes it hard for me to understand what the protocol > >>>> actually > >>>> is. > >>>> I also do not understand why H needs to be a random oracle as opposed > >>>> to > >>>> something we have in the standard model. > >>> > >>> It is difficult to understand how to act on this comment. The > >>> specification > >>> is of a cipher suite added to an existing protocol and as such has to > >>> "mix" the > >>> details of the underlying key exchange with the structure and format of > >>> the > >>> protocol it is being added to. It is not a high-level description of > the > >>> algorithm, > >>> it is a description of how to implement the key exchange as a TLS > cipher > >>> suit. > >> What protocol is this standard implementing? Where is it documented? > Where > >> is > >> the security proof? > > > > Do you have a specific comment on the draft itself? "I don't like it" > is an > > unactionable editorial comment. > Yes: the draft is unacceptable from a cryptographic perspective > because has a protocol > that has not faced formal analysis or review by the cryptographic > community, is not clearly > presented, and has no analysis worthy of the name. > The action is to write the protocol, formally prove it correct, submit > the paper to a conference > wait a few years, and then say "well, this works". Or use a theorem > verifier to shorten the time. > Rene Struik, Robert Ransom, and I all have the same opinion on the > merits of this protocol: questionable at best. > I believe this should be sufficient to prevent this draft from > becoming a standard. > > > >>>> I also do not like the language of "commitment" used. What is sent is > >>>> not a Pedersen commitment or any other recognizable commitment. > >>>> It is very malleable in ways that make me question the informal > >>>> security > >>>> analysis. > >>> > >>> Of course it's a recognizable commitment because it allows the sender > >>> to commit to a particular value (the password) without exposing it to > >>> anyone else. > >> The sender is committed to the password, but not to the value of the PE > >> point. > > > > There is a one-to-one mapping of password (plus username and salt) > > and point. If one is committed to the password, he's committed to the > > point. > No, because the point might not be from a password. He might not be able > to show > a password going to the point that he claims he was committed to, but > that doesn't necessarily > matter. Without a proof we have no idea how much it matters. Reading > the draft I don't think > the password needs to be guessed or known, but the point itself, and > the attacker isn't bound > to a choice of point. > > > >> This is noted in the "security analysis" section, but absent a proof I > >> can't tell you > >> that it doesn't matter. The security analysis section reads like a > >> bunch of attacks > >> were tried and failed. All that shows is *you* couldn't break it, not > >> that anyone else > >> couldn't. > >>> > >>>>> 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. > >>>> I think the authors wanted to specify secure curves and haddn't the > >>>> slightest to do it right. > >>> > >>> (Note: I always like to have my intelligence questioned with a > >>> statement > >>> that has multiple grammatical errors). > >> It's not your intell > > > > Again, thank you for that comment. > > > As I ment to say, but due to an editing failure did not, it is not > your intelligence I am questioning > but your ability to do cryptographic work. The present draft shows no > evidence of it. Of course, > it turns out that you weren't attempting to specify secure curves, but > unpatented ones. But all > that matter is one curve has one implementation not reached by > patents, not that the standard can only be used with unpatented > implementations > >>> As I mentioned to Rene, the reason for limiting the curves to those > >>> over a prime field with a co-factor of 1 is to avoid the patent mine > >>> field. > >> What mine field? What is so patented about cofactor>1 over prime field? > >> For binary curves I agree. > > > > There are plenty of patents that deal with acceleration when the > > cofactor is > 1 or deal with verification of received elements when > > the cofactor is > 1. I just don't want to deal with it. > And so you preemptively limit the ability of implementers to use Ed25519 if > they feel confident that it is not patented, or they don't need the > "acceleration" > that you claim is patented. It might be worthwhile to say everyone support > P256 > so we can interoperate, but why rule out particular instantiations a > priori? I just don't > get the rationale here. > > > >> But why not use whatever curve > > TLS specifies? > >> Also, why not use the existing mechanisms to deal with implementation > >> limits > >> caused by patents? > > > > What mechanisms _speciifcally_ is TLS-pwd doing that is causing you > > to say this? It uses the existing mechanisms provided by the base TLS > > protocol to convey the group to use. Again, I don't know how to address > > a comment that says to change the protocol to do what it already does. > > > >>>> Weierstrauß form has big problems: Edwards is much better from an > >>>> implementation security > >>>> perspective. Cofactor isn't enough: you also need high embedding > >>>> degree, big discriminant, > >>>> or you could just use curves we agree are good instead of reinventing > >>>> the > >>>> wheel. > > > > "[U]se curves we all agree are good instead of reinventing the wheel"? > Now > > I'm starting to think you didn't even read the draft. > We do not need 3 different places in the TLS handshake containing EC > curve parameters. > When a TLS client implementing this protocol talks to a server, it > will send this extension with > EC parameters, as well as EC parameters for the extensions permitting > EC ciphersuites to be used, > as well as special TLS ciphers saying it can use EC. This is ridiculous. > Any gains from specifying the curves are lost because of the strong > restrictions on shape. > It's entirely possible that this is the best possible result given the > current state of TLS, and my > objection to the mechanism is not strong: my strong objection is from > the lack of serious cryptographic > effort in this draft and that we have no idea how strong this protocol is. > > > > Dan. > > > >>>> Higher order protocols should be group agnostic.This prevents a major > >>>> problem when > >>>> Joux comes up with something new. > >>> > >>> It specifies a single group for interoperability purposes. It's > >>> "crypto > >>> agility" is inherited from TLS. > >>> > >>> Dan. > >>> > >>>>> 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)? > >>>> Well, one could use Elligator to solve this problem. > >>>>> > >>>>> 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 > >>>> > >>>> > >>>> > >>>> -- > >>>> "Those who would give up Essential Liberty to purchase a little > >>>> Temporary Safety deserve neither Liberty nor Safety." > >>>> -- Benjamin Franklin > >>>> _______________________________________________ > >>>> TLS mailing list > >>>> TLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tls > >>>> > >>> > >>> > >> > >> > >> > >> -- > >> "Those who would give up Essential Liberty to purchase a little > >> Temporary Safety deserve neither Liberty nor Safety." > >> -- Benjamin Franklin > >> > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] Working Group Last Call for draft-ietf-… Douglas Stebila
- [TLS] Working Group Last Call for draft-ietf-tls-… Joseph Salowey (jsalowey)
- Re: [TLS] Working Group Last Call for draft-ietf-… Blumenthal, Uri - 0558 - MITLL
- Re: [TLS] Working Group Last Call for draft-ietf-… SeongHan Shin
- Re: [TLS] Working Group Last Call for draft-ietf-… Love Hörnquist Åstrand
- Re: [TLS] Working Group Last Call for draft-ietf-… Love Hörnquist Åstrand
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Love Hörnquist Åstrand
- Re: [TLS] Working Group Last Call for draft-ietf-… SeongHan Shin
- Re: [TLS] Working Group Last Call for draft-ietf-… Ralf Skyper Kaiser
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Ralf Skyper Kaiser
- Re: [TLS] Working Group Last Call for draft-ietf-… oscar.koeroo
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Peter Sylvester
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Rene Struik
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Robert Ransom
- Re: [TLS] Working Group Last Call for draft-ietf-… Robert Ransom
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… CodesInChaos
- Re: [TLS] Working Group Last Call for draft-ietf-… Rene Struik
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Mohamad Badra
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Mohamad Badra
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Bodo Moeller
- Re: [TLS] Working Group Last Call for draft-ietf-… Robert Ransom
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Mohamad Badra
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… SeongHan Shin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… SeongHan Shin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… SeongHan Shin
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… CodesInChaos
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Joseph Birr-Pixton
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Ralf Skyper Kaiser
- Re: [TLS] Working Group Last Call for draft-ietf-… Manuel Pégourié-Gonnard
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Trevor Perrin
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins
- Re: [TLS] Working Group Last Call for draft-ietf-… Ralf Skyper Kaiser
- Re: [TLS] Working Group Last Call for draft-ietf-… Dan Harkins