Subject: Re: [TLS] New cipher suites for SRP

From: "Dan Harkins" <[email-masked]>
Date: Wed, 15 Jul 2015 12:38:03 -0700 (PDT)

On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett <[email-masked]> writes:
>> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar 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.
>> > >
>> > > 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.
>> 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.
>
> +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

  TLS-pwd already supports both of these. It also supports ECC too,
which is problematic with the current SRP protocol.

  regards,

  Dan.

---

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Fri, 17 Jul 2015 08:38:20 +0000

>which is problematic with the current SRP protocol.

I agree: Instead of modifying SRP I would prefer introducing a new PAKE
scheme. 
On CFRG I recently submitted a draft on requirements for such schemes
(https://www.ietf.org/mail-archive/web/cfrg/current/msg07005.html).

Or to be even more flexible - how about defining a generic way to include
PAKE in TLS to prevent a whole bunch of ExtensionTypes and CipherSuites by
merging them into one "PAKE_Auth"?

Best,

Jörn

---

From: Geoff Keating <[email-masked]>
Date: Fri, 17 Jul 2015 08:01:34 -0700

> On 17 Jul 2015, at 1:38 am, Schmidt, Jörn-Marc <[email-masked]> wrote:
> 

In the language of the CFRG draft, TLS-pwd is “balanced” where SRP is “augmented”,
so they’re not really equivalent, correct?

> merging them into one "PAKE_Auth”?

This is possible, but you’d need to have the client and server negotiate based on
what they have.  For example, if the server has a SRP verifier from the current
protocol, but the client has a stored PBKDF2 hash of the password for that server,
they cannot communicate and would need to pick a different cipher suite.  I am not
sure how you can do this without revealing the existence of an account under some
circumstances.  So this might be a situation where fewer protocol options is better.

---

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Mon, 20 Jul 2015 11:58:55 +0000

>so they’re not really equivalent, correct?

Correct.

>circumstances.  So this might be a situation where fewer protocol options
is better.

Of course both sides have to agree on  common protocol details: You could do
this by specifying that you want to use PAKE and refine in an extension a
set of schemes that you are capable of. 
I think there are many flavors out there that may be beneficial in specific
use-cases. I envision that e.g. in the context of the IoT with very
constrained devices (specific) PAKE schemes might be helpful. Having an
ExtensionType & corresponding CipherSuites for each of them would be way too
much. 

Best,

Jörn

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 20 Jul 2015 08:15:05 -0400

> set of schemes that you are capable of.

There's not much to negotiate. I would expend minimal energy on
negotiating parameters. The server holds the verifiers, and they are
set in stone. To get a verifier, the user needs to be pre-provisioned.

Spend energy on keeping the identity private.

If you want to go something cool, add an OTP as a second factor. There
are two ways to do it based on the math around the verifiers (that I
am aware). I have implementations for both in Crypto++, if interested.

Jeff