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

[Trevor Perrin <[e-mail]>]

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

Regarding PSK: It does not attempt to be a PAKE.  Bringing it up here
is irrelevant.


> 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

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


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

People like Tom Wu, Nikos, Quinn Slack, myself, and many others did
the "legwork" for a TLS PAKE years ago (TLS-SRP).  It was deployed in
several TLS libraries, some commercial products, and browser patches
were attempted.

We learned something very significant about TLS PAKE:  Almost no-one
wants it.  Providing usernames in the clear is an unacceptable leak of
information, and front-end TLS machines are rarely where sites wish to
perform user authentication.


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


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

To sum:  TLS already has an ad-hoc PAKE which is serviceable for those
few application which want such a thing.  We don't need another one.


Trevor