"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