Re: Bringing Tahoe ideas to HTTP

2009-09-18 Thread Peter Gutmann
Alexandre Dulaunoy adu...@gmail.com writes: On the same idea, there is an expired Internet-Draft called Link Fingerprints : http://www.potaroo.net/ietf/idref/draft-lee-uri-linkfingerprints/ Although the draft has expired, the concept lives on in various tools. For example DownThemAll for

Re: Bringing Tahoe ideas to HTTP

2009-09-18 Thread Alexandre Dulaunoy
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

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-18 Thread Peter Gutmann
Brian Warner war...@lothar.com writes: From what I can tell, the Sparkle update framework (for OS-X)[1] is doing something like what I want for firefox: the Sparkle-enabled application will only accept update bundles which are signed by a DSA privkey that matches a pubkey embedded in the app.

Re: Bringing Tahoe ideas to HTTP

2009-09-17 Thread Alexandre Dulaunoy
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

Re: Bringing Tahoe ideas to HTTP

2009-09-16 Thread Ivan Krstić
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

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-16 Thread Zooko Wilcox-O'Hearn
On Wednesday,2009-09-16, at 14:44 , Ivan Krstić wrote: Yes, and I'd be happy to opine on that as soon as someone told me what those important problems are. The message that you quoted from Brian Warner, which ended with him wondering aloud what new applications could be enabled by such

Re: Bringing Tahoe ideas to HTTP

2009-09-15 Thread Ivan Krstić
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

Re: Bringing Tahoe ideas to HTTP

2009-09-15 Thread James A. Donald
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.

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-08 Thread James A. Donald
Nicolas Williams wrote: One possible problem: streaming [real-time] content. Brian Warner wrote: Yeah, that's a very different problem space. You need the low-alacrity stuff from Tahoe, but also you don't generally know the full contents in advance. So you're talking about a mutable stream

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-09-08 Thread Brian Warner
James A. Donald wrote: Nicolas Williams wrote: One possible problem: streaming [real-time] content. Brian Warner wrote: Yeah, that's a very different problem space. You need the low-alacrity stuff from Tahoe, but also you don't generally know the full contents in advance. So

Bringing Tahoe ideas to HTTP

2009-08-31 Thread Brian Warner
[sent once to tahoe-dev, now copying to cryptography too, sorry for the duplicate] At lunch yesterday, Nathan mentioned that he is interested in seeing how Tahoe's ideas and techniques could trickle outwards and influence the design of other security systems. And I was complaining about how the

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-08-31 Thread Michael Walsh
Hi Brian, all; I'm all for including merkle trees with HTTP GETs, two items that spring to mind: - Appending the location of the hash as you suggest in #hashtree=ROOTXYZ;http://otherplace which requires no changes to the webserver. - Adding a HTTP header with this data but requires something

Re: [tahoe-dev] Bringing Tahoe ideas to HTTP

2009-08-31 Thread Brian Warner
Michael Walsh wrote: - Adding a HTTP header with this data but requires something like a server module or output script. It also doesn't ugly up the URL (but then again, we have url shortner services for manual typing). Ah, but see, that loses the security. If the URL doesn't contain the