On 071216 at 01:50, Nelson Bolyard wrote: > Steffen Schulz wrote, On 2007-12-12 10:34: > > On 071209 at 03:55, Nelson Bolyard wrote: > >> If FF doesn't have any built-in UI for SRP, I think I have a harder time > >> justifying the inclusion of SRP in NSS. I think it's a feature that > >> would be included exclusively for use in the browser, so if the browser > >> can't use it "out of the box", there may be push back on it. > > SRP is a great protocol also for authentication against your email > > provider or WLAN[1] access point. It adds KCM through the user password, > > an entity that needs to be managed anyway. > > That last sentence seems to depend on the assumption that passwords (and > more generally, shared secrets) are unavoidable, necessary, and > desirable. I don't share that view.
No, me neither. The assumption is that pw-based logins will continue to stay around quite for some time. Distribution of (useful) certificates or tokens seems to be very difficult in many environments. The (probably many) reasons for this don't seem to be all that clear and difficult to address. Maybe the breakthrough will come tommorrow morning, maybe next week. I think we should invest a little effort to tighten what we have to use every day. > But even with SRP, shared secret systems continue to have many major > drawbacks (e.g. users tend to re-use the same password for many > servers, or tend to write them down and/or store them insecurely.) Jep. > > It's not only protecting your password but also strengthens > > authentication in the face of the common PKI dilemma. > > The common PKI dilemma? I'm not very keen on discussing that stuff...what I think of as 'the' pki dilemma are the consequences of the tradeoff that is done by delegating trust relations. The introduced trust delegation concept makes the problem of distributing identity information manageable. But its still a hard problem except for closed environments *and* most people really don't understand why and when to trust Verisign to athenticate Amazon. I'd have a hard time myself to explain to my mum why one should trust verisign more than the person at the airport that I ask to look after my luggage. 'Because it would ruin their business' is pretty incomplete. That issue is actually not all of what I meant above, although the other stuff could be regarded as consequences: - people don't understand trust delegation to unknown parties(Verisign?) - most phishing sites don't even use SSL. People haven't even startet to attack SSL(maybe because it's secure) - most of the time, protocol failures are not due to attacks: its easy to do things wrong + we're still stuck with the distribution problem - It fails badly(of course I want to continue, why'd you think I clicked that link?! How would I know if it's secure before starting the transmission?) > > That said, I agree that web-authentication is the major use case > > for TLS-SRP in NSS. > Let me make my original point in another way. It was a suggestion > that you should either (a) contribute code to the browser so that it > will have the UI necessary to make use of TLS-SRP, or (b) work with > the browser developers to get them to agree to develop that code. I found previous attempts in bugzilla to do something in this area. I'll see if I can reach someone over there.. > > [1] Actually a huge problem, think of PEAP, LEAP, EAP-TLS, > > EAP-TTLS, the Cisco-crap etc. All failed attemps to provide secure > > pw-auth in a not-so-secure PKI environment. > I would have said: All attempts to keep shared secret authentication > alive in the presence of protocols that don't need it. And hopefully, with usb-tokens and smartcard readers getting cheaper, the day will come where such solutions have sufficient software support to be usable. I don't think we're there yet, it's a lot of work to deploy tokens at home and it's easy to make mistakes. I've seen the needed functionality in software suites from security vendors, expensive products that are targeted at other companies, not end users. regards, /steffen -- Bildet Olsenbanden! _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
