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

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

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.

>>   You have pointed out an issue with using an in-band server-provided
>> domain parameter set and I'm going to address that in a subsequent
>> version.
>> That's not really a flaw in the key exchange, it's how the key exchange
>> has
>> been inserted into TLS and it can be addressed by some text rewrite. I
>> am genuinely thankful for your comment and I will address it in a
>> subsequent version.
>>
>>   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 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. Now I know elliptic curve support is not a
compelling use case for you but, again, so what?

> Additionally, developments such as Elligator and AugPAKE hold promise
> for protocols that have both security proofs *and* no IPR encumbrance.

https://datatracker.ietf.org/ipr/2037/

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

  Dan.