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

From: Cullen Jennings <[email-masked]>
Date: Tue, 1 Apr 2014 11:24:08 -0600

On Mar 28, 2014, at 7:40 PM, Watson Ladd <[email-masked]> wrote:

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

Given IETF is a volunteer organization, people that think we should have a draft on X generally need to get together and write a draft on X. Asking the people that are happy with draft Y to write on draft on X is unlikely to get it done.

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Apr 2014 14:26:09 -0500

On Fri, Mar 28, 2014 at 4:49 PM, Watson Ladd <[email-masked]> wrote:
> On Fri, Mar 28, 2014 at 3:53 PM,  <[email-masked]> wrote:
>>         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.

Also, the server's need to store a password equivalent is troublesome.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Apr 2014 14:30:59 -0500

On Fri, Mar 28, 2014 at 8:40 PM, Watson Ladd <[email-masked]> wrote:
> PSK has no security? That's ridiculous: if high-entropy keys are used
> it is fairly easy to see it is secure.

TLS-PSK did not specify a PBKDF either, so it can't be used with
passwords, therefore we might as well assume high-quality keys for
TLS-PSK.  Therefore you're quite right.

Even if the server must store a password-equivalent I'd still want a
decent PBKDF to be used for any protocol that derives keying material
from passwords!

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Apr 2014 14:57:40 -0500

On Fri, Mar 28, 2014 at 7:07 PM, Dan Harkins <[email-masked]> wrote:
>> 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.

IMO:

 - user authentication generally belongs at the app layer, with
channel binding to TLS,

however

 - since there are applications where having userauth in lower layers
is convenient, it's OK to have this option in TLS,

but

 - we should use an augmented ZKPP for this.  If that means extra
round-trips or starting sooner (in the client's first message), so be
it.  We shouldn't be so constrained by the "TLS state machine" that we
make no real progress.

Finally:

 - we should use well-understood, well-aged, believed-secure
protocols.  We are constrained here by IPR, but there are protocols
which can reasonably cut through IPR FUD (e.g., J-PAKE).

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Apr 2014 13:59:09 -0700 (PDT)

> TLS-PSK.  Therefore you're quite right.

  There is nothing in the protocol that prevents it from being used with
passwords. You're not only assuming something about the nature of the
PSK, you're assuming something about the people that use the protocol
and that is quite naive.

  Furthermore making assumptions about the nature of the PSK does not
change the fact that TLS-PSK has a defect: the advantage an attacker
gains is through computation and not interaction. And for the non-DHE
ciphersuites, that defect can be exploited through passive attack!

> decent PBKDF to be used for any protocol that derives keying material

  Why? Deterministically hashing a secret 1000 times or 4000 times
does not increase the entropy in the secret. A PBKDF is just supposed
to increase the work factor of the attacker, it does nothing to the
resulting keying material.

  Wi-Fi specifies a PBKDF when using a PSK and the exchange is
essentially the same as the non-DHE TLS-PSK ciphersuites. That
protocol is horribly broken and tools exist on the Internet to attack
it. And guess what? People still use it with weak, low-entropy PSKs
in spite of assumptions to the contrary.

  Dan.

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 Apr 2014 16:16:40 -0500

> PSK, you're assuming something about the people that use the protocol

PSK requires pre-sharing the secret key.  If such presharing involves a
password then the secret key must be derived from said password.  How?
Well, the two peers have to agree.  How?  Well, it's not specified!

If there interoperable TLS-PSK w/ password implementations, then there's
a missing standard.  I have no knowledge of such implementations.

Without any further input the only reasonable conclusion is that TLS-PSK
does not support passwords.  Evidence to the contrary would be welcomed.

> ciphersuites, that defect can be exploited through passive attack!

Only if they are password-derived keys, otherwise no.

> resulting keying material.

Because verifier databases get compromised regularly.  Just point your
browser to your favorite news site and wait a few weeks, you'll see.

> in spite of assumptions to the contrary.

My concern is not eavesdroppers in this case.  See above.

Nico
--

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Apr 2014 15:30:31 -0700 (PDT)

> Well, the two peers have to agree.  How?  Well, it's not specified!

  No, the secret key IS the password, it's not derived from the password.

> does not support passwords.  Evidence to the contrary would be welcomed.

  Try openssl. It has an artificial hex checker for PSK inputs but make
your PSK be "bad" without the quotes. Works just fine.

  The presence of implementations is somewhat irrelevant since the point is
that the _specification_ allows for a PSK to be anything, it just needs to be
identical on both sides.

> Only if they are password-derived keys, otherwise no.

  No, that is wrong. Just because something is a number, or is taken
from a large space of numbers does not change the fact that the adversary
gains advantage through computation. It either passively observes a
single TLS-PSK exchange (if non-DHE) or it performs a single active attack
on a TLS-PSK user (if DHE) and then goes offline and crunches numbers
until it determines the PSK.

  Using a "high quality key" just makes that number crunching take more
time, it does not change the fundamental nature of the number crunching.
And therein lies the flaw of the TLS-PSK ciphersuites.

  A protocol that requires the adversary to gain advantage through
interaction and not through computation is vastly superior because
excessive unsuccessful interaction can be detected.

> browser to your favorite news site and wait a few weeks, you'll see.

  But that has nothing to do with how a protocol derives keying material.

> My concern is not eavesdroppers in this case.  See above.

  So what? It's an example of a protocol that uses a PBKDF being
trivially and successfully attacked. The result of the attack is that
the PSK. If the attacker chooses to use that knowledge to further
eavesdrop it's up to him. Regardless of your concern, your belief in
the power of a PBKDF seems a bit misplaced.

  Dan.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 02 Apr 2014 09:10:25 +0200

I just noticed this one sentence "PSK has no security?" and it caught my
attention.

I believe you guys are trying to misinterpet the TLS-PSK document. Maybe
you are thinking about use cases we did not envision.

TLS-PSK is not a password-based authentication mechanism for TLS!
It was never meant to be one either.

On the Web, already at that time, everyone was using passwords in forms
rather than at a lower layer in the stack. This has not changed.
(So, there was no need to standardize a password-based mechanism in TLS
at that time.)

There are very few people who are interested in using passwords in TLS
and I don't think this is the direction where deployments are going.
(Have a look at FIDO for a more promising approach of improving
authentication on the Web.)
[FWIW, I believe the strong password-based authentication and key
exchange in TLS will not lead to an improvement in password practices on
the Web.]

As a co-author of the TLS-PSK RFC I can tell you that the work was
motivated by activities in the 3GPP. The 3GPP had developed a Kerberos
alike key management protocol. The fresh and unique session key (not
password) would then be used as input to the TLS-PSK protocol.

Now, it turns out that that 3GPP work didn't really go anywhere. What we
hadn't anticipated at that time was the development on Internet of
Things where it makes sense to provision symmetric keys (not passwords)
on sensors for use with the TLS-PSK protocol. This is useful because of
(a) the excellent performance of symmetric key cryptography and (b) the
small code size.

Ciao
Hannes

On 04/02/2014 12:30 AM, Dan Harkins wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>