It is too late introducing TLS-SRP, the market will not use it.
Why not make NSS more useful for certificates instead?
Anders
On 2011-03-09 09:45, Jean-Marc Desperrier wrote:
Brian Smith wrote:
An augmented PAKE user authentication protocol might be very useful
for some things, but TLS-SRP seems very troublesome. IIRC, there are at
least four deal-breaking problems with TLS-SRP as a substitute for PKI:
I don't see it as a substitute for PKI, only as a substitute for
user/password. And my point from start was not really that NSS must
implement an EKE protocol, but that if there was one then it should be
SRP rather than JPAKE.
BTW about the patent situation, I did my research, the conclusion is
that they are various patents about everything EKE, but SRP has the
advantage above most others protocols, including JPAKE, that Stanford
owns a patent on it (the license is free for any usage) whose claims are
apparently not shared with other existing patents, so if someone wants
to claim rights on it, they'd first have to show Stanford shouldn't have
received this patent. Not that this never happens (cf
Microsoft/Lucent/Fraunhofer), but it's still much less likely than to
just to hope nobody will ever claim rights on the format you're using.
1. The user's username is sent in the clear. The user's username should be
protected.
You mean for privacy reasons, not as a way to limit brute force attacks ?
Although I don't see SRP as a replacement for PKI, I'm tempted to say
that the equivalent of the username in PKI is the certificate, and that
the certificate is not protected at all. In a SSL session with client
authentification, the client certificate is sent in the clear (except in
the case of IIS, that open a non-authenticated SSL session and
renegotiates it at the time it needs user authentication).
2. The strength of the authentication of the website to the user is
a function of the strength of that user's password; that is, a user with a
weak password will have a very weak assurance of the server's identity.
(I don't remember if this is exactly correct, but I think so.)
That seems correct to me, and that's really an important point to take
into account for the security of SRP based solution, thanks.
3. The user cannot verify the identity of the server until after the
password has been entered. However, we've trained users to enter their
passwords only after verifying the server's identity.
The rule doesn't change so much : you still need to enter your password
inside a secure element, ie if we teach user it's OK to enter their SRP
password in a non secure GUI because it won't be sent to the server we
loose.
4. You cannot identify the server until after you've created a
username/password on that server. But, account creation usually requires
giving the server personally identifying information that should be
protected by encryption and only sent after the server has been
authenticated.
Using the TLS_SRP_SHA_RSA_* cipher suites avoids problems #2 and #3
and using a non-SRP ciphersuite for account signup solves #4. But, that
requires using PKI and #1 is still a big problem.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
