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

[Watson Ladd <[e-mail]>]

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?
>
>> 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.
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
>
>   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. But why not use whatever curve TLS specifies?
Also, why not use the existing mechanisms to deal with implementation limits
caused by patents?
>
>> 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.
>>
>> 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