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.

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

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


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363