Re: [TLS] New cipher suites for SRP

["Attila Molnar" <[e-mail]>]

On 2015. 06. 27. at 5:39 AM, "Geoffrey Keating" <[e-mail]> 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.

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.

>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.

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