Subject: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-00.txt

From: Richard Barnes <[email-masked]>
Date: Wed, 11 Apr 2018 10:54:00 -0400

Hey TLS folks,

As I mentioned in my brief presentation at IETF 101, Owen and I have been
thinking about how to bring PAKE back to TLS 1.3 (since earlier SRP
mechanisms don't really apply).

We've just published an I-D describing a proposed mechanism, and I've
implemented this mechanism in the `mint` TLS 1.3 stack:

https://github.com/bifurcation/mint/pull/193

We would love to hear any feedback on the approach proposed here, and on
whether other people here would be interested in working on a PAKE
mechanism for TLS in this working group.

To address the obvious "Which PAKE?" question: We did a brief survey of the
PAKE literature, and SPAKE2 seemed like a good candidate here for a few
reasons:

- It allows a message pattern that aligns well with the TLS 1.3 handshake
- In particular, the key confirmation messages map pretty closely to the
TLS Finished MAC
- It doesn't require much in the way of exotic operations (just EC point
addition)
- It's gotten pretty robust review from CFRG

Thanks,
--Richard

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Apr 11, 2018 at 10:45 AM
Subject: New Version Notification for draft-barnes-tls-pake-00.txt
To: Richard Barnes <[email-masked]>, Owen Friel <[email-masked]>

A new version of I-D, draft-barnes-tls-pake-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:           draft-barnes-tls-pake
Revision:       00
Title:          Usage of SPAKE with TLS 1.3
Document date:  2018-04-11
Group:          Individual Submission
Pages:          7
URL:            https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-0
0.txt
Status:         https://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:       https://tools.ietf.org/html/draft-barnes-tls-pake-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake

Abstract:
   The pre-shared key mechanism available in TLS 1.3 is not suitable for
   usage with low-entropy keys, such as passwords entered by users.
   This document describes how the SPAKE password-authenticated key
   exchange can be used with TLS 1.3.

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.

The IETF Secretariat

---

From: Tony Putman <[email-masked]>
Date: Thu, 12 Apr 2018 13:23:44 +0000

Hi Richard,

I work in the IoT space and am interested in handshakes that involve little computation but offer better protection than symmetric PSK in the event of server breach.

From: TLS [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: 11 April 2018 15:54

[…]
We would love to hear any feedback on the approach proposed here, and on whether other people here would be interested in working on a PAKE mechanism for TLS in this working group.
[…]

I was interested in this draft as it seemed to tick some boxes, and I offer some comments below. But in the end I don't think it offers what I'm looking for, so I can't offer to help with it in its current form.

My main comment is that I disagree with the assertion in section 3 that "w" is effectively a salted password hash. An attacker who obtains "w" can impersonate the client to the server, so it is equivalent to a password. The only advantage is that a server breach cannot be extended to other servers where the user uses the same password, but different salts are used. It seems to me that SPAKE2+ prevents this, so perhaps this should be used instead.

Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client to know the salt. This seems unreasonable to me unless there is also some mechanism to retrieve the salt from the server. Could the salt be a hash of client identity and server identity? (I suspect there is not enough entropy in this). But in any case I think this is an issue which must be addressed in the draft.

Why does the draft need to specify what the identity of the server is? It doesn't seem to be used.

Would it be helpful to send a list of SPAKE2Shares in ClientHello? For example, if the application layer protocol is being negotiated, would it be necessary to supply shares for multiple protocols? Alternatively, if the client and/or server support multiple pre-provisioned values (G, M, N, H), how would this be signalled/managed? And would there be associated security concerns?

It is worth noting explicitly somewhere that x and y should have the same ephemeral characteristics as are used by the key_share elements, and that if this is followed then forward secrecy is provided by SPAKE2.

IMHO "w" should not be used as the PSK input. If somebody gets hold of a derived key (e.g. early_exporter_master_secret) then the low entropy of "w" may allow it to be recovered. "K" provides all that's needed for key derivation.

The draft should recommend somewhere (security section?) that H should be suitable for password hashing (e.g. Argon2) and not a standard hash function. This is particularly true if my earlier suggestion to use SPAKE2+ is followed.

Regards,
Tony

Dyson Technology Limited, company number 01959090, Tetbury Hill, Malmesbury, SN16 0RP, UK.
This message is intended solely for the addressee and may contain confidential information. If you have received this message in error, please immediately and permanently delete it, and do not use, copy or disclose the information contained in this message or in any attachment.
Dyson may monitor email traffic data and content for security & training.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 13 Apr 2018 14:50:05 -0400

Hey Tony,

Thanks for the comments.  Hopefully we can adapt this document to tick more
boxes for you :)  Since I had noticed some other errors in the document
(e.g., figures not rendering properly), I went ahead and submitted a new
version that takes these comments into account.

https://tools.ietf.org/html/draft-barnes-tls-pake-01

Some responses inline below.

On Thu, Apr 12, 2018 at 9:23 AM, Tony Putman <[email-masked]> wrote:

> Hi Richard,
>
>
>
> I work in the IoT space and am interested in handshakes that involve
> little computation but offer better protection than symmetric PSK in the
> event of server breach.
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *Richard Barnes
> *Sent:* 11 April 2018 15:54
>
> […]
>
> I was interested in this draft as it seemed to tick some boxes, and I
> offer some comments below. But in the end I don't think it offers what I'm
> looking for, so I can't offer to help with it in its current form.
>
>
>
> My main comment is that I disagree with the assertion in section 3 that
> "w" is effectively a salted password hash. An attacker who obtains "w" can
> impersonate the client to the server, so it is equivalent to a password.
> The only advantage is that a server breach cannot be extended to other
> servers where the user uses the same password, but different salts are
> used. It seems to me that SPAKE2+ prevents this, so perhaps this should be
> used instead.
>
>
>
> Secondly, SPAKE2 is fitted to the TLS 1.3 handshake by forcing the client
> to know the salt. This seems unreasonable to me unless there is also some
> mechanism to retrieve the salt from the server. Could the salt be a hash of
> client identity and server identity? (I suspect there is not enough entropy
> in this). But in any case I think this is an issue which must be addressed
> in the draft.
>

I'm not a cryptographer, but it seems to me that combining the client and
server identities would probably provide enough salt.  After all, the idea
of salt is just to make add a small degree of multiplicity to the hash.

Your point about SPAKE2+ / having the server only store public keys is
probably superseding, though.  I agree that we should try to arrange this
protocol so that the server only has to store a verifier value, but it's
not totally clear whether SPAKE2+ is needed, or whether we can use SPAKE2
and just have the server cache w*N.  After all, both w and N are fixed over
multiple runs of the protocol, so it doesn't seem like there's much benefit
to storing w and not w*N.

Given all that, I think my proposal would be:

- w = H( client identity || SNI || password ) (probably by extending the
IdentifierAndPassword struct that's in the document now)
- Client stores w or takes identities/password as input
- Server stores w*N

Maybe Ben or Watson (CCed) could comment on whether this approach seems
sound.

> Why does the draft need to specify what the identity of the server is? It

The identity field that the server sends isn't intended to be the server's
identity, but rather to indicate which of the client's offered identities
the server has selected.  The design pattern here is the same as the
key_share extension in TLS 1.3, where the server sends back a (group, key
share) pair, and the group identifies which of the client's shares the
server is using.

https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#key-share

>
> Would it be helpful to send a list of SPAKE2Shares in ClientHello? For
> example, if the application layer protocol is being negotiated, would it be
> necessary to supply shares for multiple protocols? Alternatively, if the
> client and/or server support multiple pre-provisioned values (G, M, N, H),
> how would this be signalled/managed? And would there be associated security
> concerns?
>

The ClientHello extension in the document (SPAKE2ClientHello) already
allows the client to send multiple SPAKE2Shares.  Note, however, that the
only thing that can be negotiated is which identity/password is to be
used.  The current document assumes that the group (and thus G, M, N) and
the hash function (H) are fixed / pre-negotiated based on the identity.

I can understand why people might want negotiation, but it does seem safer
to me to only ever use a given password with the same group and hash.  It's
also consistent with the "server stores w*N" approach above.

> It is worth noting explicitly somewhere that x and y should have the same
> ephemeral characteristics as are used by the key_share elements, and that
> if this is followed then forward secrecy is provided by SPAKE2.
>

Agreed.

> IMHO "w" should not be used as the PSK input. If somebody gets hold of a
> derived key (e.g. early_exporter_master_secret) then the low entropy of "w"
> may allow it to be recovered. "K" provides all that's needed for key
> derivation.
>
>
Agreed.  Using "w" in the key schedule also means that the server has to
have it.  As noted above, this is bad.

> The draft should recommend somewhere (security section?) that H should be
> suitable for password hashing (e.g. Argon2) and not a standard hash
> function. This is particularly true if my earlier suggestion to use SPAKE2+
> is followed.
>

Agreed.

--Richard

> This message is intended solely for the addressee and may contain
> confidential information. If you have received this message in error,
> please immediately and permanently delete it, and do not use, copy or
> disclose the information contained in this message or in any attachment.

---

From: Tony Putman <[email-masked]>
Date: Mon, 16 Apr 2018 09:50:20 +0000

Hi Richard,

I don't think that you can protect against server compromise with SPAKE2. The server can store w*N as you suggest, but it also has to store w*M because it must calculate y*(T-w*M). An attacker that learns w*M and w*N from a compromised server can then impersonate a client. 

The rest of your comments I agree with (though they are not all addressed in the updated draft). 

Tony

> From: Richard Barnes [mailto:[email-masked]] 
> Sent: 13 April 2018 19:50
>
> Hey Tony,
>
> Thanks for the comments.  Hopefully we can adapt this document to tick more boxes for you :)  
> Since I had noticed some other errors in the document (e.g., figures not rendering properly), 
> I went ahead and submitted a new version that takes these comments into account.
>

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 16 Apr 2018 11:52:28 +0000

Hi Richard,

A few nits.

* In the introduction you have the sentence
> DISCLAIMER: This is a work-in-progress draft of MLS and has not yet

   seen significant security analysis.

Iiuc this draft has no connection to MLS, and this is a typo.

 * In the setup you define

> o  A DH group "G" of order "p*h", with "p" a large prime

and

> o  A password "p"

The variable "p" has two different meanings, which is a bit confusing,
especially later on.

 * The document doesn't explicitly state that X and Y need to be non-zero.
The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if the
warning was carried through.

* In terms of security properties, iiuc an active adversary can do online
password guessing attacks, but a passive adversary cannot derive the
password from observing the messages. If that is the case perhaps a warning
about rate-limiting connection attempts is appropriate.

Regards,

Jonathan

On Mon, 16 Apr 2018 at 10:50 Tony Putman <[email-masked]> wrote:

> Hi Richard,
>
> I don't think that you can protect against server compromise with SPAKE2.
> The server can store w*N as you suggest, but it also has to store w*M
> because it must calculate y*(T-w*M). An attacker that learns w*M and w*N
> from a compromised server can then impersonate a client.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Apr 2018 14:43:26 -0400

Hey Jonathan,

Thanks for the comments.  I've implemented them in my working copy of the
draft, and in my implementation in mint.  I have also changed it over to
use SPAKE2+; I agree with Tony that this is necessary to guard against
server compromise.

https://github.com/bifurcation/tls-pake/commit/a9f097c3bfe43cf50001e1a340c7e2e693850d4b
https://github.com/bifurcation/mint/pull/193

With regard to security properties: I don't think it's correct that an
active attacker can do online password guessing.  Everything that is
revealed on the wire is blinded with fresh, per-connection entropy, and
thus doesn't reveal anything about the password.

--Richard

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 16 Apr 2018 18:59:18 +0000

Hi Richard,

That's correct, however if I have a guess of the password can I not just
try and connect using that password?
If my guess is correct then the connection will succeed, whereas if my
guess is incorrect then the connection will fail.
I'm assuming here that the salt is public, because salts in general do not
have confidentiality guarantees (otherwise they stretch the metaphor and
become pepper).
(I also assume that the client identity can be derived from observing a
previous session, and that the server identity can be identified through
probing.)

Regards,

Jonathan

On Mon, 16 Apr 2018 at 19:43 Richard Barnes <[email-masked]> wrote:

>>> I don't think that you can protect against server compromise with
>>> SPAKE2. The server can store w*N as you suggest, but it also has to store
>>> w*M because it must calculate y*(T-w*M). An attacker that learns w*M and
>>> w*N from a compromised server can then impersonate a client.
>>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Apr 2018 15:01:21 -0400

> guess is incorrect then the connection will fail.

Sure, but aren't you going to have that with any password-authenticated
protocol?

--Richard

>>> The requirement is in "I-D.irtf-cfrg-spake2", but it would be nice if
>>> the warning was carried through.
>>>
>>> * In terms of security properties, iiuc an active adversary can do
>>> online password guessing attacks, but a passive adversary cannot derive the

---

From: Jonathan Hoyland <[email-masked]>
Date: Mon, 16 Apr 2018 19:06:53 +0000

You are, but it's not mentioned in the security section.
As it's a security consideration that you don't get in vanilla TLS I feel
that it should be mentioned.

Regards,

Jonathan

On Mon, 16 Apr 2018 at 20:01 Richard Barnes <[email-masked]> wrote:

>> I'm assuming here that the salt is public, because salts in general do
>> not have confidentiality guarantees (otherwise they stretch the metaphor
>> and become pepper).
>>> Thanks for the comments.  I've implemented them in my working copy of
>>> the draft, and in my implementation in mint.  I have also changed it over
>>> to use SPAKE2+; I agree with Tony that this is necessary to guard against
>>> server compromise.
>>>
>>>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Apr 2018 15:22:47 -0400

Oh, sure.  In a similar vein, an attacker can also probe for which
identities are known to the server.

https://github.com/bifurcation/tls-pake/commit/0e72bd5244e89970fe61e5434ca7df3d769d057c