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

[Trevor Perrin <[e-mail]>]

On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins <[e-mail]> wrote:
>
>
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <[e-mail]> wrote:
>>>
>>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>>>> Dan Harkins <[e-mail]>:
>>>>
>>>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>>>> results.
>>>>
>>>>
>>>> While it is true that Joe noted that, I think the point of the present
>>>> discussion is that the protocol wasn't actually reviewed by the CFRG
>>>> with
>>>> satisfactory results.
>>>
>>>   No, that's not really true.  There is a difference between "your
>>> protocol has
>>> not been proven secure" and "your protocol has a security flaw". And
>>> while
>>> the former has been pointed out on this list and the CFRG list, the
>>> later
>>> has not.
>>
>> Yes, it has.  Bodo pointed out a security flaw.
>
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.

I did.  Bodo pointed out a security flaw, despite your attempts to spin it.


>>>   The present discussion on the list boils down to these subjects:
>>>
>>>   1) there's no security proof and that is unacceptable (Rene, Watson)
>>>   2) there's nothing special about this protocol so why don't you (being
>>>       me) spend your time working on something else that we (Rene,
>>>       Watson) think is better.
>>>   3) the TLS-pwd benefits and your use cases are not compelling to
>>>       me (Trevor).
>>>
>>> The response to #1 is that security proofs have never been required
>>> and we have standards-track protocols today that are susceptible to
>>> offline dictionary attack (every PSK cipher suite). So it's an appeal to
>>> a
>>> process that does not exist.
>>
>> At Watson points out, times have changed and the bar is higher now.
>
>   You are appealing to a process that does not exist.

The process for acquiring trust in new cryptographic algorithms is
widely understood to involve (A) rigorous security proofs, and (B)
succesfully withstanding years of cryptanalysis (particularly
important if lacking A).

You have neither.


>>> The response to #2 is that lack of implementation of these other
>>> protocols has been hampered by patents
>>
>> See the discussion around SRP that occurred when you first presented
>> this.  Any patent FUD which *might* have existed, once, has expired:
>>
>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves.

Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
which could be used as the basis for a DH-EKE style PAKE.


>>> The response to #3 is: so? There is rarely uniformity in viewpoints
>>> as everyone's experience is different. Now there's a choice and if
>>> the benefits of one are not compelling then be happy you can
>>> choose the other.
>>
>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>> has nothing to do with this draft's cryptographic differences.  It has
>> to do with architectural issues with the approach, which your draft
>> does not improve on.
>
>   You are free to not use this protocol as well if you do not find it
> compelling.

We should not standardize protocols which are inferior to existing
ones and to newer alternatives, have insufficient cryptographic
analysis, have no application, and have no support in the WG beside
the draft authors and the NSA [2].

I remain opposed.


Trevor

[1] https://eprint.iacr.org/2013/325.pdf
[2] http://www.ietf.org/mail-archive/web/tls/current/msg08371.html