Re: [TLS] New cipher suites for SRP

["Dan Harkins" <[e-mail]>]

On Mon, June 29, 2015 4:31 am, Hubert Kario wrote:
> On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote:
>> Dave Garrett <[e-mail]> 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.