Re: TLS-SRP (was Re: J-PAKE in NSS)
On Wed, 9 Mar 2011, Anders Rundgren wrote: It is too late introducing TLS-SRP, the market will not use it. Uh? There's not just one single market that will or won't use a particular protocol feature. There are plenty of different areas where TLS is used and some of them will use TLS-SRP, and some even already are. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
On 2011-03-10 09:32, Daniel Stenberg wrote: On Wed, 9 Mar 2011, Anders Rundgren wrote: It is too late introducing TLS-SRP, the market will not use it. Uh? There's not just one single market that will or won't use a particular protocol feature. There are plenty of different areas where TLS is used and some of them will use TLS-SRP, and some even already are. TLS-SRP doesn't do anything that certificates do not do better. If SRP had been available in the browser it could have been important. But it failed, hard. Anders -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
Jean-Marc Desperrier wrote: I don't see it as a substitute for PKI, only as a substitute for user/password. If you want SRP but don't need TLS-SRP then you could implement SRP outside of NSS and then build the UI support around that non-NSS support as a HTTP 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 ? Both. In particular, if somebody learned that my Gizmodo username/password was bsm...@mozilla.com/bieber4ever, then when they see bsm...@mozilla.com in the clear they can just try to break into the connection using that password. But, also, I do not want to tell everybody in every Starbucks I go to my email address. 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). Yes, this is a problem that needs to be fixed in TLS and worked around (as much as possible) in implementations. I just filed https://bugzilla.mozilla.org/show_bug.cgi?id=640745 about this. The same could be done for TLS-SRP, but you would need to authenticate the server first using PKI. 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. It's hard to explain what a secure element is to somebody. It's much easier to say make sure the address bar turns green and says 'PayPal, Inc.' but even that's asking too much most of the time. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
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
Re: TLS-SRP (was Re: J-PAKE in NSS)
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
TLS-SRP (was Re: J-PAKE in NSS)
Jean-Marc Desperrier wrote: But Curl, that supports secret keys from version 7.21.4, with GnuTLS only at the moment but is pushing hard to get in in Openssl also, apparently has simply given up about having TSP-SRP support when compiled with NSS. I see in an old doc that Johnathan was considering SRP support in Firefox for 3.next ( https://wiki.mozilla.org/Firefox/3.next/hitlist ). 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: 1. The user's username is sent in the clear. The user's username should be protected. 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.) 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. 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. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS-SRP (was Re: J-PAKE in NSS)
On Mon, 7 Mar 2011, Brian Smith wrote: But Curl, that supports secret keys from version 7.21.4, with GnuTLS only at the moment but is pushing hard to get in in Openssl also, apparently has simply given up about having TSP-SRP support when compiled with NSS. Can I just add that we (in the curl project) haven't given up on anything - we're an open source project and we will of course support whatever our users and developers want and make happen. curl supports 7 different SSL libraries (including NSS) and if some of the libs don't have the necessary features, we provide these specific features only when built with a lib featuring them. TLS-SRP is an example of a feature that seemingly only GnuTLS delivers out of the box right now. 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: There are places for both ways I'd say, and it seems there are users out there who think so. I don't think many people argue that it substitutes PKI to any greater extent. -- / daniel.haxx.se -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
