Re: [TLS] I-D Action: draft-ietf-tls-pwd-04.txt

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

On Fri, March 28, 2014 4:35 pm, Watson Ladd wrote:
> On Fri, Mar 28, 2014 at 6:55 PM, Dan Harkins <[e-mail]> wrote:
>>
>> On Fri, March 28, 2014 2:49 pm, Watson Ladd wrote:
>>> On Fri, Mar 28, 2014 at 3:53 PM,  <[e-mail]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>> directories.
>>>>  This draft is a work item of the Transport Layer Security Working
>>>> Group
>>>> of the IETF.
>>>>
>>>>         Title           : Secure Password Ciphersuites for Transport
>>>> Layer Security (TLS)
>>>>         Authors         : Dan Harkins
>>>>                           Dave Halasz
>>>>         Filename        : draft-ietf-tls-pwd-04.txt
>>>>         Pages           : 35
>>>>         Date            : 2014-03-28
>>>
>>> Why should we trust this PAKE? I've got only partial results in this
>>> direction, but they are not sufficient for me to adopt it when better
>>> validated alternatives exist like those based on distrustful MPC.
>>
>>   I'm not sure what you mean by "we" but it got quite a bit of review
>> in CFRG and that resulted in fixing the only real technical issue
>> brought
>> up: potential for a side-channel attack. Scott Fluhrer came up with a
>> way to do a random blinding of a value when checking whether its a
>> quadratic residue that effectively addresses that concern.
>
> "We didn't break it in the four months we've looked at it" is not a
> good enough reason.
> Given that the experts you have consulted have expressed doubts about
> ever determining its security, I'm inclined to be rather more
> suspicious of it.

  It's been more like 2 years, but nevertheless, your complaint is a
lack of formal security proof. But that has never been a requirement
for a draft in a WG in the Security Area, or any area for that matter,
of the IETF.

> During the last half of those two months I was trying to show it would
> work. The best I can do is reduce it to the two person case, but I
> can't get it to anything computational.

  What a drag, I was hoping you'd come up with something.

>>   These ciphersuites are drop-in replacements for things like PSK
>> ciphersuites, not for popular ones used in browsers. In fact, I agree
>> with several on this list who are pointing out that using a PAKE in a
>> browser is not a good idea.
>
> Why is a multi-party computation ala Socialist Millionaire's protocol
> in OTR not feasible? That establishes a secure channel based on a
> password shared on both ends in a way that is provably secure.
> Aug-PAKE can easily be made to work symmetrically: why can't you use
> that?

  There is no draft specifying a multi-party computation ala the
Socialist Millionaire's protocol in TLS, much less one that is as
mature as TLS-pwd. Aug-PAKE doesn't work in TLS, as shown
by draft-shin-tls-augpake-- what's conveyed in the ClientKeyExchange
structure since the client's contribution has been overloaded into
the ClientHello? Basically, the client must initiate in Aug-PAKE and
that forces a square peg into a round hole, or introduces extra
rounds.

  We have gone over this before, but it takes years to get a draft
in the state necessary to become an RFC. You said it took more
like 30 minutes, but I'm sure you'd like to reevaluate that after
your experience with the CFRG I-D you have been writing. In
any event, the only draft _right now_ that satisfies the requirements
is TLS-pwd.

> There are standard models for PAKE security. Does Dragonfly work in
> them? It clearly requires the ROM: is that enough?
>
> You're asking this WG to approve adding a new cryptographic protocol
> to TLS with dubious justifications, in fact nonexistent, of security,
> when a well-studied body of knowledge on this problem exists. There is
> a compelling case for a PAKE: there is not a compelling case for
> Dragonfly.

  The same WG that approved of RFC 4279, a Standards Track RFC that
did not have a proof in the ROM because it has no security. Yes, that same
WG. I'm proposing a set of robust and misuse-resistant replacements for
the RFC 4279 ciphersuites.

  regards,

  Dan.

> Sincerely,
> Watson Ladd
>>
>>   If you're happy doing cert-based TLS, or happy with HTTP Digest
>> authentication (or whatever) then these are not for you. But the
>> entirety
>> of networking  is not "the web" and these ciphersuites work well with
>> some specific use cases (see the draft).
>>
>>   regards,
>>
>>   Dan.
>>
>>
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>