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

[Watson Ladd <[e-mail]>]

On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins <[e-mail]> wrote:
>
> 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.
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
>>>>>> [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
>>
>



-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin