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
Re: J-PAKE in NSS
Brian Smith wrote: Jean-Marc Desperrier wrote: [...] (I'd expect it instead to leave the AES256 key inside NSS and just get back the handle to it to encrypt what it needs later. [...]). The kind of improvement you described above will be made to resolve Bug 443386 and/or Bug 638966. I think Bug 638966 is slightly different, it's about permanently storing the secret keys in the NSS db (I don't know if that's really possible, typically the db only stores privates keys). Doing this could solve bug 443386 except that SRP is not a FIPS approved algorithm so I'm sure if the module ought to still be able to do SRP when in FIPS mode. [...] The resolution of Bug 443386 will change that interface in a non-backward-compatible way (except for Sync, which will get modified to use the new interface in lockstep). You are considering to remove PBKDF2 ? If so, the encrypted result will be incompatible before/after the move ? I am very interested in what you want to use SRP for (especially other than Sync). If I need SRP, I can have it in an extension, it's just a pity to not get it from NSS. 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 ). -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE in NSS
Jean-Marc Desperrier wrote: Brian Smith wrote: The kind of improvement you described above will be made to resolve Bug 443386 and/or Bug 638966. I think Bug 638966 is slightly different, it's about permanently storing the secret keys in the NSS db (I don't know if that's really possible, typically the db only stores privates keys). Softoken may have to be enhanced to support storing Sync (or generic) keys for this to work. Doing this could solve bug 443386 except that SRP is not a FIPS approved algorithm so I'm sure if the module ought to still be able to do SRP when in FIPS mode. See https://bugzilla.mozilla.org/show_bug.cgi?id=443386#c19 (comment 19). The same would apply to SRP. You are considering to remove PBKDF2 ? If so, the encrypted result will be incompatible before/after the move? PBKDF2 was already replcaed with HKDF. - Brian -- 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
Re: J-PAKE in NSS
Jean-Marc Desperrier wrote: I notice the committed code extracts the generated shared symmetric key up to the javascript level, so takes no real advantage from having generated it inside NSS (I'd expect it instead to leave the AES256 key inside NSS and just get back the handle to it to encrypt what it needs later. It seems they believe they *must* be able to extract the key, but I don't really understand why). This was done this way because of the desire to change the JavaScript parts of Sync as little as possible. The kind of improvement you described above will be made to resolve Bug 443386 and/or Bug 638966. BTW, it's a bit disappointing to see the javascript so entangled with the specificities of J-PAKE, when the P11 layer below maps it to generic PK11_KeyGenWithTemplate / PK11_DeriveWithTemplate / PK11_Derive operations. We don't intend to expose J-PAKE to anything except Sync. The resolution of Bug 443386 will change that interface in a non-backward-compatible way (except for Sync, which will get modified to use the new interface in lockstep). Also, I am hoping to move *all* of the lower-level Sync crypto stuff from Javascript into its own native-code implementation exposed with more Sync-specific APIs. See Bug 636309. I am very interested in what you want to use SRP for (especially other than Sync). Maybe there is some way to get your SRP-based ideas working in Firefox without waiting around for us to take some action on it. Lets start a new thread (privately or on this mailing list) about that. - Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE in NSS
Robert Relyea wrote: So the end result : I see that J-PAKE code got included inside NSS https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to access it from js (bug 601645). This was not announced here, and even if it looked like Sync Would keep J-PAKE, I did not imagine it would be included as a new mechanism in NSS, I thought it would stay inside an external layer. It's a crypto authentication mechanism. It involves keys. I needs to be in NSS if we are to support it at all. (which is why it's there;). It involves no key, in the usual meaning of a secret permanent key, which makes it *possible* to implement it externally. I notice the committed code extracts the generated shared symmetric key up to the javascript level, so takes no real advantage from having generated it inside NSS (I'd expect it instead to leave the AES256 key inside NSS and just get back the handle to it to encrypt what it needs later. It seems they believe they *must* be able to extract the key, but I don't really understand why). Now it's certainly the most sensible things to do to have all crypto be handled by NSS. But I thought J-PAKE was intended as an as quick as possible hack, which is why the Sync team was so reluctant to switch to using SRP (unless it was proven J-PAKE was cryptographically weak), despite SRP being much more widely used (and having already several open bugs, with patch even, requesting it's inclusion in NSS/Firefox). Seeing the J-PAKE patch, it would be quite fast to rewrite it using SRP instead of J-PAKE using the existing SRP patch (CKM_NSS_JPAKE_ROUND1-ROUND2_SHAxxx/CKM_NSS_JPAKE_FINAL_SHAxxx would change to CKM_NSS_SRP_SERVER_KEY_PAIR_GEN/CKM_NSS_SRP_DERIVE, etc.), it's totally equivalent functionally, we'd just add a small step where the server, before deriving the shared key, make a call to generate the password verifier from the password. BTW, it's a bit disappointing to see the javascript so entangled with the specificities of J-PAKE, when the P11 layer below maps it to generic PK11_KeyGenWithTemplate / PK11_DeriveWithTemplate / PK11_Derive operations. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: J-PAKE in NSS
On 02/28/2011 08:20 AM, Jean-Marc Desperrier wrote: For context, from a message I wrote in last October : Given the number of protocols that include SRP (SSL/TLS, EAP, SAML), given that there's already a proposed patch for NSS (bug 405155, bug 356855), a proposed patch for openssl ( http://rt.openssl.org/Ticket/Display.html?id=1794user=guestpass=guest ), I still think SRP is the better choice since the effort to implement it would be much more widely useful than with J-PAKE. On the long term, I wouldn't be surprised if at some point you'll add another scenario where augmented security would be useful, and you will in all likehood stay the only users of J-PAKE, I believe SRP will certainly end up being included, and it will be a little stupid to have 2 functionally equivalent algorithms. So the end result : I see that J-PAKE code got included inside NSS https://bugzilla.mozilla.org/show_bug.cgi?id=609076 with a layer to access it from js (bug 601645). This was not announced here, and even if it looked like Sync Would keep J-PAKE, I did not imagine it would be included as a new mechanism in NSS, I thought it would stay inside an external layer. It's a crypto authentication mechanism. It involves keys. I needs to be in NSS if we are to support it at all. (which is why it's there;). bob I really, really regret I gave up on that dead-end discussion about J-PAKE and did not follow what happened exactly after that. It would have been just functionally equivalent for Sync to use SRP instead of J-PAKE in Sync, but so much more useful for everyone else, especially for all those who would love to be able to use SRP with TLS. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
