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

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

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.

  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.

The response to #2 is that lack of implementation of these other
protocols has been hampered by patents and TLS-pwd is not
patented (and the underlying dragonfly key exchange is not patented
either). Theoretically I think there are some elegant alternatives to
TLS-pwd but practically I don't think there are. Regardless though,
there is nothing stopping Rene and/or Watson from doing any work
on any other protocol they think should be advanced. Since I am not
their slave^H^H^H^H^Hgrad student I do not feel compelled to
throw away my work and write papers and wait years as has been
suggested.

(The little uptake in PAKE protocols in the IETF in the recent years is
the result of people following me around from EMU to IPsecme and
now to TLS and after I do the leg work and present a dragonfly-style
exchange someone else comes along and says "hey, me too").

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.

  To sum, there has been no demonstration of a flaw against the
dragonfly protocol, just some people unhappy that I don't live up
to their standards or that my views of what is important in a PAKE
protocol is not congruent to theirs.

  regards,

  Dan.