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
