Re: Bringing Tahoe ideas to HTTP
On Fri, Sep 18, 2009 at 6:27 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: Although the draft has expired, the concept lives on in various tools. For example DownThemAll for Firefox supports this. There was some discussion about including it into FF3, but then the draft was dropped and the FF support never appeared, does anyone know what happened? It was a SoC project within Mozilla but seeing the following discussion : https://bugzilla.mozilla.org/show_bug.cgi?id=377245 The state looks a bit unclear to me... (The cynic in me would say it's such a simple, straightforward, easy-to- implement idea, of course it'll never be adopted when there are things like EV certs to be pushed instead, but who knows...). mode type=cynic Right... When I see the EV audit process[1], it looks to me like PCI DSS without the technical aspect... /mode [1] http://cabforum.org/WebTrustAuditGuidelines.pdf -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance --that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Thu, Aug 27, 2009 at 11:57 PM, Brian Warner war...@lothar.com wrote: == Integrity == To start with integrity-checking, we could imagine a firefox plugin that validated a PyPI-style #md5= annotation on everything it loads. The rule would be that no action would be taken on the downloaded content until the hash was verified, and that a hash failure would be treated like a 404. Or maybe a slightly different error code, to indicate that the correct resource is unavailable and that it's a server-side problem, but it's because you got the wrong version of the document, rather than the document being missing altogether. On the same idea, there is an expired Internet-Draft called Link Fingerprints : http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/ I made some experiments around while used as Machine Tag/Triple Tag[1] : http://www.foo.be/cgi-bin/wiki.pl/MachineTagLinkFingerprint to have an extension with OpenPGP detached signature. Another potential use, it's to benefit from the number of users checking the integrity and contribute back the computed value into a tagging system like del.icio.us or any other collaborative bookmarking. I especially like the Firefox (or wget,curl) extension that could compute the hash value and check it against various contributed hashes. That could give a kind of confidence level regarding the integrity of the file and its corresponding URL/URI. Just some ideas, adulau [1] http://www.foo.be/cgi-bin/wiki.pl/MachineTag -- -- Alexandre Dulaunoy (adulau) -- http://www.foo.be/ -- http://www.foo.be/cgi-bin/wiki.pl/Diary -- Knowledge can create problems, it is not through ignorance --that we can solve them Isaac Asimov - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Sep 15, 2009, at 4:12 PM, James A. Donald wrote: The ideas used in Tahoe are useful tools that can be used to solve important problems. Yes, and I'd be happy to opine on that as soon as someone told me what those important problems are. -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
On Aug 27, 2009, at 2:57 PM, Brian Warner wrote: I've no idea how hard it would be to write this sort of plugin. But I'm pretty sure it's feasible, as would be the site-building tools. If firefox had this built-in, and web authors used it, what sorts of vulnerabilities would go away? What sorts of new applications could we build that would take advantage of this kind of security? What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. It bugs the hell out of me when smart, technical people spend time and effort devising solutions in search of problems. You need to *start* with the sorts of vulnerabilities you want to do away with, or the kinds of new applications you can build that current security systems don't address, and *then* work your way to solutions that enable those use cases. It's okay to do it in reverse order in the academia, but you seem to be talking about real-world systems. And in real-world systems, you don't get to play Jeopardy with cryptography. Cheers, -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
Re: Bringing Tahoe ideas to HTTP
Ivan Krsti wrote: What you're proposing amounts to a great deal of complex and complicated cryptography. If it were implemented tomorrow, it would take years for the most serious of implementation errors to get weeded out, and some years thereafter for proper interoperability in corner cases. In the meantime, mobile device makers would track you down for the express purpose of breaking into your house at night to pee in your Cheerios, as retaliation for making them explain to their customers why their mobile web browsing is either half the speed it used to be, or not as secure as on the desktop, with no particularly explicable upside. The ideas used in Tahoe are useful tools that can be used to solve important problems. It is true that just dumping them on end users and hoping that end users will use them correctly to solve important problems will fail It is our job to apply these tools, not the end user's job, the hard part being user interface architecture, rather than cryptography protocols. Yurls are one example of an idea for a user interface wrapping Tahoe like methods to solve useful problems. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
