Subject: Standardizing Firefox's Implementation of Link Fingerprints

From: "Edward Lee" <[email-masked]>
Date: Mon, 2 Jul 2007 16:24:10 -0700

For Firefox 3, there are patches [1] that implement Link Fingerprints,
which provide automatic resource verification for URIs that look like
http://site.com/file#hash(sha256:abc123) so that link providers can be
sure that end users download the exact file that the provider intended
(and not a trojaned download).

The fragment identifier portion of the URI is used for backwards
compatibility with existing clients while allowing for extended usage
across protocols (e.g., http, ftp) and resource contexts (e.g., a
href, img src). Additionally, fragment identifiers are not sent as
part of a HTTP request, so the network and servers do not need to be
changed. With the backwards compatibility, incremental deployment is
feasible with some clients supporting Link Fingerprints, and end users
don't need to do anything unless there's a fingerprint failure.

An initial draft to standardize Link Fingerprints is available online..

https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt

Feedback is welcome about the design, syntax, supported hashes,
failure cases, etc.

Ed

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=377245

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jul 2007 17:43:17 -0700

> (and not a trojaned download).

Although this sounds like an entirely reasonable option to add to URLs, I'm 
curious just how much of a problem there is with downloads that are trojaned 
using the correct domain name?

For this hashing to be useful, it means that either my client needs to land on 
a surrogate machine or the correct machine needs to be compromised.  In either 
case, the hashing would seem to be useful, on the theory that the hash value 
is vetted when it is developed and is then distributed through an 
uncompromised path.

I'm merely curious how big a problem any of this currently is?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Edward Lee" <[email-masked]>
Date: Mon, 2 Jul 2007 17:57:47 -0700

> using the correct domain name?

One main use case of Link Fingerprints is for file mirroring networks.
The portal server with high security can link to 3rd party mirrors
that may or may not have the correct file that is being distributed.
With just some clients supporting Link Fingerprints, the users that
see the problem can report to the site administrator to quickly
resolve the problem.

For a recent example, WordPress announced on March 2, 2007 that some
copies of version 2.1.1 was hijacked.

"It was determined that a cracker had gained user-level access to one
of the servers that powers wordpress.org, and had used that access to
modify the download file. We have locked down that server for further
forensics, but at this time it appears that the 2.1.1 download was the
only thing touched by the attack. They modified two files in WP to
include code that would allow for remote PHP execution." [1]

Ed

[1] http://wordpress.org/development/2007/03/upgrade-212/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 02 Jul 2007 18:00:29 -0700

> modify the download file. We have locked down that server for further

Thanks.

d/

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Jul 2007 22:42:14 -0400

great idea in principle, but somehow, using fragment identifiers for
this seems like it's incompatible with the normal use of fragment
identifiers.  I guess I see little danger that these will collide with
"real" fragment IDs, but somewhat more danger that a browser or other
parser will look at a document containing such URIs and do something
reasonable with it.

---

From: Philip Guenther <[email-masked]>
Date: Mon, 2 Jul 2007 21:22:32 -0600

> (and not a trojaned download).

This sounds a lot like the hash-scheme for making text fragment 
identifiers robust that's proposed in

    http://www.ietf.org/internet-drafts/draft-wilde-text-fragment-06.txt

The goals are not quite parallel as the above doesn't support hashing 
without also specifying a position, while your draft pictures a general 
syntax for schema and content-type independent signing.  The overlap does 
seem considerably though, if just because a content-type independent 
method would render the text/plain specific one obsolete.

Putting general object metadata in the fragment seems contorted though. 
For the hash-scheme stuff in draft-wilde-text-fragment there's at least a 
tenuous association with positioning information, but even then it's a 
stretch.

(Is there any normal textual representation for an http URL plus an etag 
or other identity verifier?  imap URLs put the mailbox UIDVALIDITY, which 
is an identity verifier for the mailbox as an object, in the path part.)

Philip Guenther
Sendmail, Inc.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 03 Jul 2007 11:13:25 +0200

> https://people.mozilla.com/~edilee/draft-lee-uri-linkfingerprints-00.txt

I believe standardizing this would be useful.

There is another use case for this idea: referencing X.509 certificates.
Some protocols -- TLS client_certificate_url extension, and the DNS CERT
resource record -- already have support for something similar, where a
URL needs to be accompanied with a hash in order to be useful.  Placing
the hash value in the URL itself is a simple improvement, and will
simplify future protocols that want to do similar things as TLS/CERT.
These future protocols can have only a URL field, and require that the
URL contains a linkfingerprint.

An origin of the hash-value-in-URL idea is the WTLS, if you can find a
reference to it, it may be useful to add a informative reference to it.
There may be other similar examples too, but I don't know of any earlier
one.

/Simon

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 24 Jul 2007 00:06:01 -0500

Why is this scheme better than an HTML extension
<a href="url" hash="md5:12345">
?