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. I'll agree that SRP is an improvement over most other protocols for shared-secret based authentication, and that if the application REQUIRES shared secret authentication, it's a good way to go. 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.) > It's not only protecting your password but also strengthens > authentication in the face of the common PKI dilemma. The common PKI dilemma? > 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. NSS generally only includes features that are wanted and used by at least one of the major products that use NSS. NSS shared libraries don't include many features that aren't used by any of those products. (The exception to this rule are old features that have fallen into disuse, such as the old "export" cipher suites, and SSL2, but those were widely used when they were added.) Most major new contributions of code to NSS in the past, such as the ECC code in NSS 3.11 or the Camellia code for NSS 3.12, or the DHE code (a few years back) have been accompanied by patches to extend the browser UI as necessary to enable these new features to be used in the browser. In other cases, the browser UI development was done by the Mozilla core UI developers themselves. For SRP, the issue is that presently there doesn't appear to be any mozilla product (or other major NSS-based product) that is asking for TLS-SRP support. So, unless the UI code is contributed along with SRP, the new TLS-SRP code will be an orphan, a feature in NSS that none of NSS's major users use. That could (and I think would) prove to be an impediment to including TLS-SRP in NSS. It would be fine if a representative of an NSS-based product spoke up and said "Yeah, we'd really like to have SRP, and would do the work to support it in our product if it was added to NSS." But I haven't read anything like that yet. > [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. /Nelson _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
