Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Adam Back a...@cypherspace.org writes: EKE for web login is decades overdue and if implemented and deployed properly in the browser and server could pretty much wipe out phishing attacks on passwords. We have source code for apache, mozilla, maybe could persuade google; and perhaps microsoft and apple could be shamed into following if that was done. Mozilla has said they won't be supporting it, for a reason so astonishingly boneheaded that I'll quote the original message to make sure that it's straight from the horse's mouth (PSK cipher suites = non-patent-encumbered EKE in TLS-talk): -- Snip -- Subject: Re: NSS implementation of TLS-PSK/ RFC 4279 Date: Tue, 14 Oct 2008 14:01:10 -0700 From: Nelson B Bolyard nel...@bolyard.me Reply-To: mozilla's crypto code discussion list dev-tech-cry...@lists.mozilla.org jeng...@berkeley.edu wrote, On 2008-10-14 13:52 PDT: I was wondering if implementation of TLS-PSK (RFC 4279) is currently in development. I do not see it in the current NSS source or roadmap. Thank you for any help. -John Engler No. There are no plans to include any PSK cipher suites in NSS. Because of the enormous potential for PSK cipher suites to be misused by application developers, there is strong resistance to incorporating them into NSS. -- Snip -- As for Microsoft, Opera, etc who knows? (If you work on, or have worked on, any of these browsers, I'd like to hear more about why it hasn't been considered). I think it'll be a combination of two factors: 1. Everyone knows that passwords are insecure so it's not worth trying to do anything with them. 2. If you add failsafe mutual authentication via EKE to browsers, CAs become entirely redundant. So the browser vendors' approach is to ignore EKE and keep on waiting for PKI to start working, forever if necessary. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Hi, On 07/13/2011 01:34 PM, Ian G wrote: Is there any reason why the ssh client-side can't generate the key, take the password from the user, login and install the key, all in one operation? Hm, I think there's actually a tool to do just that, although I don't remember the name. You'd probably still have to disable password access. Ralph -- Dipl.-Inform. Ralph Holz I8: Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
On 2011-07-13 9:10 PM, Peter Gutmann wrote: As for Microsoft, Opera, etc who knows? (If you work on, or have worked on, any of these browsers, I'd like to hear more about why it hasn't been considered). I think it'll be a combination of two factors: 1. Everyone knows that passwords are insecure so it's not worth trying to do anything with them. 2. If you add failsafe mutual authentication via EKE to browsers, CAs become entirely redundant. Indeed, if EKE is implemented in the most straightforward way, any page or data that can only be accessed while logged in, is securely encrypted even if accessed over http. Free browsers are supported by CAs. EKE enabled browsers would only be supported by people needing secure logins, which form a less concentrated interest, therefore an interest less capable of providing public goods. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
On Wed, Jul 13, 2011 at 2:17 PM, James A. Donald jam...@echeque.com wrote: On 2011-07-13 9:10 PM, Peter Gutmann wrote: As for Microsoft, Opera, etc who knows? (If you work on, or have worked on, any of these browsers, I'd like to hear more about why it hasn't been considered). I think it'll be a combination of two factors: 1. Everyone knows that passwords are insecure so it's not worth trying to do anything with them. 2. If you add failsafe mutual authentication via EKE to browsers, CAs become entirely redundant. Indeed, if EKE is implemented in the most straightforward way, any page or data that can only be accessed while logged in, is securely encrypted even if accessed over http. Free browsers are supported by CAs. EKE enabled browsers would only be supported by people needing secure logins, which form a less concentrated interest, therefore an interest less capable of providing public goods. I believe Mozilla is [in]directly supported by Google. Mozilla has made so much money, they nearly lost their tax exempt status: http://tech.slashdot.org/story/08/11/20/1327240/IRS-Looking-at-GoogleMozilla-Relationship. I was also talking with a fellow who told me NSS is owned by Red Hat. While NSS is open source, the validated module is proprietary. I don't use NSS (and have no need to interop with the library), so I never looked into the relationship. Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
On 07/13/2011 01:33 PM, Jeffrey Walton wrote: I believe Mozilla is [in]directly supported by Google. Mozilla has made so much money, they nearly lost their tax exempt status: http://tech.slashdot.org/story/08/11/20/1327240/IRS-Looking-at-GoogleMozilla-Relationship. Mozilla has a lot of cash in the bank and it gets a large majority of its revenue from its contract with Google. I was also talking with a fellow who told me NSS is owned by Red Hat. While NSS is open source, the validated module is proprietary. I don't use NSS (and have no need to interop with the library), so I never looked into the relationship. Google, Mozilla, and Red Hat all employ people who maintain NSS. They're nice folks, just look them up in the source tree and email them if you have any questions. - Marsh ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
On 14/07/11 4:33 AM, Jeffrey Walton wrote: On Wed, Jul 13, 2011 at 2:17 PM, James A. Donaldjam...@echeque.com wrote: On 2011-07-13 9:10 PM, Peter Gutmann wrote: As for Microsoft, Microsoft have a big interest in bypassing the status quo, and they've tried several times. But each time it isn't for the benefit of the users, more for their own benefit, in that they've tried to rebuild the security infrastructure with themselves in control. (recall .net, InfoCard, Brands' patents, etc.) Nothing wrong with that, they have to pay for it somehow. This has proven ... a harder nut to crack than they envisage. But at least they are trying, my hat goes off to them! Opera, etc who knows? (If you work on, or have worked on, any of these browsers, I'd like to hear more about why it hasn't been considered). I think it'll be a combination of two factors: 1. Everyone knows that passwords are insecure so it's not worth trying to do anything with them. 2. If you add failsafe mutual authentication via EKE to browsers, CAs become entirely redundant. Indeed, if EKE is implemented in the most straightforward way, any page or data that can only be accessed while logged in, is securely encrypted even if accessed over http. Free browsers are supported by CAs. Well, not financially, more like the policy side is impacted by the CAs, which are coordinated in a confidential industry body called CABForum. This body communicates internally to Mozilla (being a member) and via private comment by CAs to the CA desk. Against that are a small and noisy but also uncoordinated group of user representatives. As we're punching against an organised, paid opponent that can't be seen, we don't get very far. They (Mozilla, other vendors and the CAs) are in the process of raising the standards yet again for CAs, on the back of various claimed breaches of certs and rising angst against all security problems. Because they have laid out their architecture, and because it makes money, they aren't about to change it. But they are bedding it in. The chances of them approving or agreeing to EKE are next to nil. EKE enabled browsers would only be supported by people needing secure logins, which form a less concentrated interest, therefore an interest less capable of providing public goods. I believe Mozilla is [in]directly supported by Google. Mozilla has made so much money, they nearly lost their tax exempt status: http://tech.slashdot.org/story/08/11/20/1327240/IRS-Looking-at-GoogleMozilla-Relationship. I was also talking with a fellow who told me NSS is owned by Red Hat. While NSS is open source, the validated module is proprietary. I don't use NSS (and have no need to interop with the library), so I never looked into the relationship. Possibly, I haven't heard that. The problem with Mozilla security coding is more this: most (all?) of the programmers who work in that area are all employees of the big software providers. And they all have a vested interest in working for the status quo, all are opposed to any change. (Not because they are bad or good, but because that's what they are paid to do.) (It doesn't help to offer help either; they have their ways of rejecting any asymmetric help.) iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Ian G wrote: Well, not financially, more like the policy side is impacted by the CAs, which are coordinated in a confidential industry body called CABForum. This body communicates internally to Mozilla (being a member) and via private comment by CAs to the CA desk. AFAIK, the CABForum has a very limited influence on Mozilla's CA inclusion policy and all of our CA policy discussions are public: http://groups.google.com/group/mozilla.dev.security.policy/topics?pli=1 The chances of them approving or agreeing to EKE are next to nil. The problem with Mozilla security coding is more this: most (all?) of the programmers who work in that area are all employees of the big software providers. And they all have a vested interest in working for the status quo, all are opposed to any change. * https://wiki.mozilla.org/Identity/Features/Verified_Email_Service https://wiki.mozilla.org/Identity/Verified_Email_Protocol * https://wiki.mozilla.org/Security/DNSSEC-TLS https://bugzilla.mozilla.org/show_bug.cgi?id=589537 * http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg10018.html https://bugzilla.mozilla.org/show_bug.cgi?id=532127 https://bugzilla.mozilla.org/show_bug.cgi?id=405155 https://bugzilla.mozilla.org/show_bug.cgi?id=356855 * http://www.usenix.org/events/sec11/tech/ SSL/TLS Certificates: Threat or Menace? Moderator: Eric Rescorla, RTFM, Inc. Panelists: Adam Langley, Google; Brian Smith, Mozilla; Stephen Schultze, Princeton University; Steve Kent, BBN Technologies Cheers, Brian ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Ian G i...@iang.org writes: Microsoft have a big interest in bypassing the status quo, and they've tried several times. But each time it isn't for the benefit of the users, more for their own benefit, in that they've tried to rebuild the security infrastructure with themselves in control. (recall .net, InfoCard, Brands' patents, etc.) Actually they do have one thing they've done that no other browser has, they have, as of IE9, a single mechanism that goes beyond has a certificate - good, no certificate - bad that all the other browsers use, which is their SmartScreen reputation-based handling of executable downloads (not to be confused with the mostly pointless blacklisting mechanism, which confusingly is also called SmartScreen). Unfortunately all the figures they give for its effectiveness are yes-biased (what's in the other three sectors of the contingency table?), and so far there hasn't been any rigorous assessment of its effectiveness, but they are the only browser vendor that's even made an effort to look beyond the cert/no cert boolean option. (In addition, Infocard was an attempt at building a better auth.infrastructure, not necessarily motivated by owning the market. The problem there was that it was sold as Microsoft Infocard, if they'd called it OpenSomethingorother, say OpenID, then no-one would have had a problem with it). Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] ssh-keys only and EKE for web too (Re: preventing protocol failings)
Ian G wrote: The chances of them approving or agreeing to EKE are next to nil. The problem with Mozilla security coding is more this: most (all?) of the programmers who work in that area are all employees of the big software providers. And they all have a vested interest in working for the status quo, all are opposed to any change. On 2011-07-14 10:41 AM, Brian Smith wrote: * https://wiki.mozilla.org/Identity/Features/Verified_Email_Service https://wiki.mozilla.org/Identity/Verified_Email_Protocol * https://wiki.mozilla.org/Security/DNSSEC-TLS https://bugzilla.mozilla.org/show_bug.cgi?id=589537 * http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg10018.html https://bugzilla.mozilla.org/show_bug.cgi?id=532127 https://bugzilla.mozilla.org/show_bug.cgi?id=405155 https://bugzilla.mozilla.org/show_bug.cgi?id=356855 Perhaps you think these links suggest that mozilla is not in the pocket of the CAs, in that some people at mozilla are attempting to make DNSEC actually useful. But they are going to make it useful by making the DNS into a super CA. You are still going to have to buy your certificate from an existing CA, and the DNS system will bless it. This like designing a bicycle with three and half wheels. Any restructuring that makes DNSSEC useful would make the CAs useless. The goal of their design is not to make DNSSEC useful, but to make it useful in a fashion that does not harm the CA business model. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
