On Mon, June 29, 2015 4:31 am, Hubert Kario wrote: > On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote: >> Dave Garrett <davemgarr...@gmail.com> 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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
