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

From: [email-masked]
Date: Fri, 28 Mar 2014 12:53:34 -0700

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

Abstract:
   This memo defines several new ciphersuites for the Transport Layer
   Security (TLS) protocol to support certificate-less, secure
   authentication using only a simple, low-entropy, password.  The
   ciphersuites are all based on an authentication and key exchange
   protocol that is resistant to off-line dictionary attack.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-pwd-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 17:49:16 -0400

>         Filename        : draft-ietf-tls-pwd-04.txt

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.

Sincerely,
Watson Ladd

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 28 Mar 2014 15:55:28 -0700 (PDT)

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

  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.

  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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 19:35:05 -0400

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

> 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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 28 Mar 2014 17:07:41 -0700 (PDT)

On Fri, March 28, 2014 4:35 pm, Watson Ladd wrote:
>>>>  This draft is a work item of the Transport Layer Security Working
>>>> Group
>>>> of the IETF.
>>>>

  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.

> can't get it to anything computational.

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

> Aug-PAKE can easily be made to work symmetrically: why can't you use

  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.

> a compelling case for a PAKE: there is not a compelling case for

  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.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 28 Mar 2014 21:40:42 -0400

> for a draft in a WG in the Security Area, or any area for that matter,

So because I didn't complain when the Security Area was founded, I
don't get to complain now?
This takes estoppel to a bizarre extreme.

> that forces a square peg into a round hole, or introduces extra

Write one. It's your problem, not mine.

As for AugPAKE, that might be ugly, but it works. I'm not seeing a
barrier to implementation here. Furthermore, we could reverse the
roles of client and server if we wanted a symmetric version in which
the client talks first.

> any event, the only draft _right now_ that satisfies the requirements

The concerns I have with Dragonfly cannot be fixed by fiddling with
verbiage. They are fundamental problems with the protocol presented
compared to the state of the art.

> the RFC 4279 ciphersuites.

PSK has no security? That's ridiculous: if high-entropy keys are used
it is fairly easy to see it is secure.

Dragonfly's "robustness" and "misuse-resistence" are nothing but
rhetoric, absent some reason to believe it actually has these
properties.

Sincerely,
Watson Ladd