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

"Dan Harkins" <dharkins@lounge.org> Tue, 03 December 2013 22:51 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 1C38F1AE164 for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 14:51:55 -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 75QICbeIelWB for <tls@ietfa.amsl.com>; Tue, 3 Dec 2013 14:51:52 -0800 (PST)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 89F011ADED9 for <tls@ietf.org>; Tue, 3 Dec 2013 14:51:52 -0800 (PST)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 749C4A888012; Tue, 3 Dec 2013 14:51:49 -0800 (PST)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 3 Dec 2013 14:51:49 -0800 (PST)
Message-ID: <07e8735a16897ea72465ffb12f7a744f.squirrel@www.trepanning.net>
In-Reply-To: <529DE795.5060203@gmail.com>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <529C990D.3020608@gmail.com> <6b51bc68470b316cf6d38c7033c0d451.squirrel@www.trepanning.net> <529DE795.5060203@gmail.com>
Date: Tue, 03 Dec 2013 14:51:49 -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 22:51:55 -0000

  Hi Rene,

On Tue, December 3, 2013 6:15 am, Rene Struik wrote:
> Hi Dan:
>
> I could not find that CFRG had a LC on this. In case I missed this,
> please kindly provide a pointer.
>
> Triggered by the TLS WG LC, I decided the review the Dragonfly protocol
> document last Friday (since TLS WG LC suggested CFRG had "blessed" this)
> and sent my review to the CFRG email reflector. One can find this review
> here:http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127
> <http://permalink.gmane.org/gmane.ietf.irtf.cfrg/2127>.
>
> I suggest you have a discussion on how to fix security comments raised
> on the CFRG dragonfly protocol on that list.

  Already done. Thank you for your comments there, they will improve the
document. As you noted there your "review comments… *strictly* apply
to the latest CFRG draft only; the related TLS draft will be dealt with
separately." So I'm glad these two are not linked in your mind.

> As far as I am concerned, my TLS WGLC comments still stand.

  So what would you like me to do about them? Please comment below.

> Best regards, Rene
>
> On 12/3/2013 3:27 AM, Dan Harkins wrote:
>>    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.

  Your curiosity on advantages dragonfly has over other exchanges is
not really a comment on the draft unless you are suggesting adding
such a section. Are you?

  Similarly, there is no statement of "specialness" in the draft so your
inability to determine its specialness is also not really anything to do
with something in the draft. Do you want a section on "specialness
considerations"? If so, can you point to any other similar types of
drafts/RFCs that have such a section?

>>> 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.

  Indeed, this was done. The delta from -01 to -02 of the CFRG draft is
irrelevant to the draft under discussion here on this thread. There is no
LC on the IRTF draft but you can take that up with David and Kevin. There
are no changes possible to the draft under question regarding what the
CFRG is doing so I'm not sure how to resolve your comment.

>>> 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.

  We seem to disagree on this. I view binary curves and those with a
co-factor > 1 as problematic so the limitation is a feature.

  If you would like to make a case on why avoiding a patent minefield
is not a good thing to do we can try and gauge WG consensus on the
issue.

>>> 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.

  If this comment stands then explain what you'd like to see done to the
draft to address it. The technique is already deterministic and you seem to
want to remove non-determinism from it so I'm not sure what you're
looking for here.

  regards,

  Dan.

>>    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
>>>
>
>
> --
> email: rstruik.ext@gmail.com | Skype: rstruik
> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>
>