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

["Dan Harkins" <[e-mail]>]

On Tue, December 3, 2013 8:12 am, Watson Ladd wrote:
> On Tue, Dec 3, 2013 at 12:50 AM, Dan Harkins <[e-mail]> wrote:
>>
>> On Mon, December 2, 2013 8:40 am, Watson Ladd wrote:
>>> On Mon, Dec 2, 2013 at 6:28 AM, Rene Struik <[e-mail]>
>>> 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.

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

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

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

  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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>>
>>>>
>>>> --
>>>> email: [e-mail] | Skype: rstruik
>>>> cell: [phone] | US: [phone]
>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> [e-mail]
>>>> 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
>>> [e-mail]
>>> 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
>