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
