Re: Comment on tls-srp enhancement?
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
Re: Comment on tls-srp enhancement?
Hi, On 071213 at 16:30, Michael Ströder wrote: Steffen Schulz wrote: SRP is a great protocol also for authentication against your email provider or WLAN[1] access point. [..] That said, I agree that web-authentication is the major use case for TLS-SRP in NSS. Hmm, without having looked at tls-srp but from my experience SSL/TLS connections are quite often terminated at a reverse proxy. But the password-based authentication information is passed to an application server beyond that reverse proxy which checks the password by some means. I guess in case of tls-srp the reverse proxy (as TLS end point) would have also to check the password. This is not what most of my customers deploying reverse proxies want. What is definitely needed for larger environments is the ability to do user authentication at the backend, not at the web server or whatever your SSL endpoint may be. SRP does not need its transmissions to be secured in any way, so there is no problem in relaying the data to somewhere else. And, it may be bad design or an otherwise flawed idea, but TLS-SRP in NSS includes a PKCS11 interface that does exactly this: Relaying all protocol data to a an entity that holds long-term secrets and does all authentication, returning only the common session key to SSL. (Lucky me, there is some use to the pkcs11-stuff after all.. ;-) ) /steffen -- Holzhacken ist deshalb so beliebt, weil man bei dieser Tätigkeit den Erfolg sofort sieht. -- Albert Einstein ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
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. It's not only protecting your password but also strengthens authentication in the face of the common PKI dilemma. That said, I agree that web-authentication is the major use case for TLS-SRP in NSS. So the plan was to create a FF extension instead. One that 'fixes' how the security status is displayed(and perceived, hopefully), and also includes some other ideas with regards to phishing attacks. Then the patch against PSM should be very small if needed at all. I hope this way it will be easier to settle on the way the security interface should work and it may also help to evaluate how some other ideas perform. Easier? Because it's easier to obtain forgiveness than permission? :-) Because the usability of such an interface is easier to evaluate and debug when it does not exist as a outdated crude patch to mozilla cvs head. It's an primarily an academic project. Anyway. I'll try to find my way through the code that handles NSS. It'll probably go a lot faster for someone who knows psm or c++, but I guess there all busy, too.. regards, /steffen [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. -- Getting there isn't half the fun, it's all the fun. -- Robert Townsend ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
Steffen Schulz wrote, On 2007-12-07 19:50: On 071208 at 01:25, Nelson Bolyard wrote: [snip] Do you have a companion bug/RFE for adding the necessary UI support to PSM (Personal Security Manager), the Mozilla software component that does UI for crypto-related issues? Having SRP in NSS won't do much good unless the necessary UI is also present. No patch as of now. Larry from FF3 displays the identity of the server as the main aspect, but with SRP there may be mutual authentication but no certificate information at all. I also personally dislike Larry. Now if I write a PSM patch, I'd have to integrate it into the existing security interface. A lot of fuss about sth that is IMHO inherently broken. 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. So the plan was to create a FF extension instead. One that 'fixes' how the security status is displayed(and perceived, hopefully), and also includes some other ideas with regards to phishing attacks. Then the patch against PSM should be very small if needed at all. I hope this way it will be easier to settle on the way the security interface should work and it may also help to evaluate how some other ideas perform. Easier? Because it's easier to obtain forgiveness than permission? :-) [snip] Regards, /steffen Regards, /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Comment on tls-srp enhancement?
Steffen Schulz wrote, On 2007-12-07 07:43: I was hoping for some feedback on bug 405155, which adds support for TLS-SRP. Are the core devs that busy right now? The NSS team has lost 3 staff members this year, and those of us who remain are very busy, yes. We're (hopefully) nearing the end of a pretty major product release, for NSS version 3.12, and there's lots to do. New requests for enhancement (RFEs) that request that the NSS team do the work are not getting much attention now. In your case, you have attached a patch, and (I gather) you're seeking review of the patch (a necessary precursor to commitment). Bugzilla has a way to mark a patch with a review request. Doing so causes that patch to appear on some reviewers queue of patches to be reviewed. Most patch reviewers only review patches that show up in their review request queues. But your patch has not been marked with a review request. I'll add some suggestions in that bug on how to proceed. (I also thought subscribing to this list would enable me to follow the current development around nss/psm. Do you just use bugzilla?) This list gets used for lots of purposes, including: - communication between the NSS developers and the developers of other products that use NSS (including the Mozilla client products). You could call this developer support (as opposed to end user support). - discussions of Mozilla trusted root CA certificates and the policy that controls them. - occasional end user or server admin questions of the form why doesn't Firefox like my certificate? - other topics of interest to the community of developers who use or develop NSS. But it's not used much for direct day-to-day communications among the NSS developers themselves. They tend to use direct email or bugzilla or occasional phone calls. Discussions about specific bugs generally take place in the bugs themselves, unless they need to involve a larger community. You're certainly welcome to start discussions of SRP in TLS here. Do you have a companion bug/RFE for adding the necessary UI support to PSM (Personal Security Manager), the Mozilla software component that does UI for crypto-related issues? Having SRP in NSS won't do much good unless the necessary UI is also present. Getting new UI approved is MUCH more difficult than getting new crypto approved, IMO, and I'm afraid that it's too late in the FF3 development schedule to start that, if it isn't already started. There might be plenty of time for SeaMonkey though. Mozilla UI discussions generally do NOT take place in this list. Unfortunately, there isn't one single other list in which they mostly do take place, but rather there are many other lists. I'd suggest starting in dev-security (a.k.a the mozilla.dev.security newsgroup). Regards, /Nelson ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Comment on tls-srp enhancement?
Hi all, I was hoping for some feedback on bug 405155, which adds support for TLS-SRP. Are the core devs that busy right now? (I also thought subscribing to this list would enable me to follow the current development around nss/psm. Do you just use bugzilla?) regards, steffen -- Bildet Olsenbanden! ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
