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

[Watson Ladd <[e-mail]>]

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.

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.

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

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