Subject: [TLS] New cipher suites for SRP

From: "Attila Molnar" <[email-masked]>
Date: Sat, 27 Jun 2015 01:48:01 +0200

Hello,

Currently SRP cannot be used with newer crypto primitives such as ciphers in
AEAD mode or SHA-2 due to the lack of cipher suites enabling these.
There's only 3DES and AES-CBC with SHA-1.

Would there be support for expanding the SRP cipher suites?

Regards, Attila

---

From: Dave Garrett <[email-masked]>
Date: Fri, 26 Jun 2015 21:01:56 -0400

> Would there be support for expanding the SRP cipher suites?

I don't think it's a good idea to add new SRP cipher suites.

Instead, I think redefining SRP as an extension to PSK would make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get similar capabilities. This would make updating SRP to use newer crypto much easier, as modern PSK cipher suites are easier to get standardized. The current SRP spec actually already appears to rely on PSK identity alert codes.

Dave

---

From: Geoffrey Keating <[email-masked]>
Date: 26 Jun 2015 20:39:24 -0700

> Instead, I think redefining SRP as an extension to PSK would make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get similar capabilities. This would make updating SRP t…

The problem with that is that there are surely many use cases where
you're willing to do SRP, or if no SRP you can do a regular ECDHE and
prompt for the username/password, but PSK is too insecure.

I've been thinking an improved SRP would be useful.  It should:

- Specify Modern cipher and hash algorithms as mentioned above

- Replace the existing SHA1+seed with a password whitening function
  like PBKDF2, so that in the event of a compromised server cracking
  the password is harder, and also making online password guessing
  attacks (sending lots of username+password pairs to the server) more
  expensive*

- Deprecate the 1024-bit and the 1536-bit group, and the previous SRP
  ciphersuites; and say that these should only be chosen if the server
  has a legacy verifier for a particular username which requires
  them.

*: You can even keep two verifiers for each account: a 'fast' one
 where PBKDF2 should execute in a fraction of a second, and a 'slow'
 one where PBKDF2 might take 15-30 seconds, and pick between them
 based on recent account history, IP address reputation, or whatever.
 It costs the server no more to use the 'slow' path but anyone
 guessing passwords will find it much less effective.

---

From: "Attila Molnar" <[email-masked]>
Date: Sun, 28 Jun 2015 23:24:04 +0200

On 2015. 06. 27. at 5:39 AM, "Geoffrey Keating" <[email-masked]> wrote:
>> Instead, I think redefining SRP as an extension to PSK would 
>make more sense. Use (EC)DHE_PSK cipher suites with an updated SRP 
>extension to get similar capabilities. This would make updating 
>SRP to use newer crypto much easier, as modern PSK cipher suites 
>are easier to get standardized. The current SRP spec actually 
>already appears to rely on PSK identity alert codes.

Interesting solution, but doesn't this create corner cases e.g. when both SRP
and PSK are supported?
They are probably solvable one way or the other, though.

However if TLS 1.3 will allow pairing key exchanges with ciphers etc. on the
fly all work on this becomes wasted time.

> guessing passwords will find it much less effective.

Some thoughts that apply to both suggestions:

- Specification-wise they are both significantly more complex than adding new
cipher suites.

- Same for implementations. Adding cipher suites is very simple if the crypto
primitives are already there, and is more likely to happen compared to adding
new logic.

As a result of these two, it will take a considerably longer time for applications
to be able to make use of the result of either of the mentioned ideas (if an
enhanced SRP ever gets implemented).

Because of its abandonment, as of now TLS-SRP cannot be recommended to be used
in place of ad hoc, less secure application protocols.
The reason I suggested adding new cipher suites is that it seems to be a good
tradeoff: it's a drop-in remedy for a major problem with SRP.

I understand that it is me who wants to see it updated so it is also me who
has to do the lion's share of the work.
I thought that expanding the cipher suite arsenal is a good enough treatment
for the short term for SRP, but if the WG thinks otherwise and rather wants a
bigger overhaul I'm willing to work on that too to improve the unfortunate
situation of SRP in TLS.
However, I'd like to see a consensus on a TODO first.

What do you think about this? Are the original authors of TLS-SRP still
interested in it?

Please discuss.

Regards, Attila

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Jun 2015 13:31:18 +0200

On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
> > > Currently SRP cannot be used with newer crypto primitives such as
> > > ciphers in AEAD mode or SHA-2 due to the lack of cipher suites enabling
> > > these. There's only 3DES and AES-CBC with SHA-1.
> > > 
> > Instead, I think redefining SRP as an extension to PSK would make more
> > sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to get
> > similar capabilities. This would make updating SRP to use newer crypto
> > much easier, as modern PSK cipher suites are easier to get standardized.
> > The current SRP spec actually already appears to rely on PSK identity
> > alert codes.

+1, provided we do two more things:

 - Change the negotiation so that user name is not exchanged in the clear
 - Change key exchange to do PFS

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 29 Jun 2015 09:20:23 -0400

>  - Change key exchange to do PFS
The clear text username/email will generate a security related
finding. I suffered on a couple of years ago when using email
addresses.

The wording should allow flexibility. Something like 'identity' or
'identity representation' so either the email or a hash of the email
(or another way to identify the user) can be sent.

It seems like a chicken-and-the-egg problem. The client won't know
what to send until the server responds with what it consumes based on
the organization's security posture.

Jeff

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Jun 2015 15:24:21 +0200

> the organization's security posture.

what I meant, is that we may need to wait for TLS1.3 standardisation before we 
can update the SRP ciphersuites to a standard at which browsers like Firefox 
will agree to ship it

---

From: Tom Wu <[email-masked]>
Date: Mon, 29 Jun 2015 06:55:59 -0700

>  - Change key exchange to do PFS

SRP already provides PFS automatically.

Tom

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Jun 2015 15:57:24 +0200

> SRP already provides PFS automatically.

I'm rather fuzzy about the details (I've read the RFC quite a bit ago), but 
isn't the server key share static in SRP?

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 29 Jun 2015 10:05:53 -0400

> isn't the server key share static in SRP?
No.

Here's the step that calls out its a random key (from RFC 5054):

    2.5.3.  Server Key Exchange

   The server key exchange message contains the prime (N), the generator
   (g), and the salt value (s) read from the SRP password file based on
   the user name (I) received in the client hello extension.

   The server key exchange message also contains the server's public
   value (B).  The server calculates this value as B = k*v + g^b % N,
   where b is a random number that SHOULD be at least 256 bits in length
   and k = SHA1(N | PAD(g)).

Things like resumption can affect the forward secrecy, though. But all
cipher suites suffer it equally.

Jeff

---

From: Hubert Kario <[email-masked]>
Date: Mon, 29 Jun 2015 16:07 +0200

> cipher suites suffer it equally.

ahh, I stand corrected, thanks