[Ach] Fwd: Re: !SRP

[Philipp Gühring]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

Am 2013-12-18 23:48, schrieb Adi Kriegisch:
> Hi!
>
>> Ivan Risti? agrees that we should remove !SRP.
>> Peter Gutmann also suggests to use TLS-SRP (or TLS-PSK) instead of any
>> other ciphersuites for password-authentication in his upcoming book
>> "Engineering Security" in several places. (From my point of view,
>> TLS-SRP seems a bit more safe than TLS-PSK for password-authentication,
>> I would use TLS-PSK for embedded and other special applications)
> Thanks for providing more insights!
>
> Actually I am still not convinced that removing '!SRP' from the cipher
list
> is a good idea:
Well, it was not added for security reasons, but just to keep things
simple for testing.
But we have security reasons to remove it, to improve
password-authentication for TLS.
> SRP requires special configuration in any way.
> Enabling a security mechanism that isn't configured may lead to undesired
We aren?t enabling it this way, we don?t want to disable it.
Normally, SRP is allowed (for most applications out there), unless it is
forbidden in the config with !SRP.
>
> side effects and I'm afraid, we'll only know what may happen when
> web/imap/whatever servers begin supporting SRP.


Most clients and servers support client-certificate authentication, but
nearly nobody uses them, and they also need additional configuration to
activate them. But I have not heard yet about any undesired effects when
they are not configured, so I do not expect such problems with SRP.
Any undesired effects are an implementation issue of a specific
implementation, which most likely can and should be fixed by the
respective vendor.
Most software currently shipped comes with Ciphersuite defaults that do
not disable SRP by default, and some servers already support SRP, so if
there were any security relevant side effects, I would have expected
that we had heard about it already.

The only potential problem I could think of is that an implementation
could (wrongly) announce the SRP ciphersuite(s) to the TLS peer if it
isn?t configured, and that some peer that supports SRP would then
perhaps choose that ciphersuite, try it, fail, and then not try again
with a different ciphersuite, and then fail completely. But this should
be easy to fix for the vendor, to simply not announce SRP ciphersuites
unless they are correctly configured, or easy to workaround for admins
by adding !SRP if they really need it.
But I hope/expect TLS and SRP implementers to think about that and make
sure that their products only announce SRP when it?s configured, and
think that we don?t need to worry about that problem until it really
show up.

SRP is the "better crypto" for password authentication on TLS, instead
of sending the password inside the TLS tunnel and have it being
decrypted on the other end again.
I think that SRP should be the preferred ciphersuite for POP3S, IMAPS
and SMTP-Submission and similar protocols that are practically always
password authenticated. (in comparison to https, where you want
anonymous access to read websites)
(Except if client certificates are already in use)


> Anyone else having an opinion on that?
>
> Probably you could provide more explanations for section 7.3 (choosing
your
> own ciphers). What we have right now:
> Key Exchange:
> "Other key exchange mechanisms like Pre-Shared Key (PSK) or Secure Remote
>  Password (SRP) are irrelevant for regular SSL/TLS use."
I would remove "or Secure Remote Password (SRP) " from that sentence,
since it is actually relevant for regular SSL/TLS use, especially for
password-authentication applications like POP3S, SMTPS-Submission, IMAPS.
Pre-Shared Key is irrelevant for regular SSL/TLS use, it?s necessary for
embedding it into applications that do key-agreement in another way or
through a different channel, but not for regular SSL/TLS use.
>
> (which is a little misguided)
>
> and Authentication:
> "In addition to the server providing its identity, a client might do so as
>  well. That way mutual trust can be established. Another mechanism
providing
>  client authentication is Secure Remote Password (SRP) [ADD REFERENCE]
>  All those mechanisms require special configuration."
>

Reference: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol

Best regards,
Philipp Gühring
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlKyRJ0ACgkQlqQ+F+0wB3rJVgCgka/4jroLWy3VFbYNtZQXLjfA
rWIAoKVArKuCIXoEFk6RUvlqOZGnFy4h
=VCM9
-----END PGP SIGNATURE-----