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

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

On Tue, December 3, 2013 10:08 am, Watson Ladd wrote:
> On Tue, Dec 3, 2013 at 9:41 AM, Dan Harkins <[e-mail]> wrote:
[snip]
>>   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.

  That is not a comment on the draft but on the process.

  Nothing is stopping you from working on some protocol that you
find value in and working to achieve consensus on it being the right
way to go but work was done on this protocol and consensus was
reached in the WG to proceed with it. The exchange was reviewed
by the CFRG with, as Joe noted, satisfactory results.

  You think that is unacceptable? OK, point noted.

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

  No, the attacker is free to choose any point he wants. But since there is
a one-to-one mapping of password (plus username plus salt) to point
any guess of the password that is incorrect will produce the wrong point.
That's the whole point (pun intended).

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

  Whether you're questioning my intelligence or my ability to do crypto
is another unactionable editorial comment. And frankly I don't really
care whether you are impressed with my abilities or not.

>                        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

  No, I'm not specifying any curves. I'm just disallowing certain ones.

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

   Because patents tend to be written generally to cover more than
"particular instantiations".

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

  I don't think you understand how TLS works. It is necessary to convey
the particular curve to use and it is necessary to convey the information
required by the key exchange (i.e. the commitment).

  Again, if you have a _specific_ comment on how to do this differently,
I'm all ears. As was mentioned in the last call notice, "[t]he document
needs particular attention paid to the integration of this mechanism
into the TLS protocol." You seem to imply you have some way to
improve its integration into the TLS protocol. So instead of questioning
my ability or expressing your personal dissatisfaction that not enough
papers were written and years passed before this draft was written
maybe you can make a concrete and relevant comment to help improve
things. If not, then thank you for your most impressive soliloquy on
Edwards curves, Weierstrauss, big discriminants and the ever-fearful
"what will Joux do next".

  Dan.

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