headers
Edward Lee | 3 Jul 01:24
Gravatar

Standardizing Firefox's Implementation of Link Fingerprints

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
Permalink | Reply | 7 comments |
headers
Dave Crocker | 3 Jul 02:43

Re: Standardizing Firefox's Implementation of Link Fingerprints


Edward Lee wrote:
> 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).

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
Permalink | Reply | 2 comments |
headers
Edward Lee | 3 Jul 02:57
Gravatar

Re: Standardizing Firefox's Implementation of Link Fingerprints

On 7/2/07, Dave Crocker <dhc <at> dcrocker.net> wrote:
> 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?

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/
Permalink | Reply | 1 comment |
headers
Dave Crocker | 3 Jul 03:00
Favicon
Gravatar

Re: Standardizing Firefox's Implementation of Link Fingerprints


Edward Lee wrote:
> 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

Thanks.

d/

d/
--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply | 0 comments |
headers
Keith Moore | 3 Jul 04:42
Picon

Re: Standardizing Firefox's Implementation of Link Fingerprints

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.

> 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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philip Guenther | 3 Jul 05:22
Favicon

Re: Standardizing Firefox's Implementation of Link Fingerprints

On Mon, 2 Jul 2007, Edward Lee wrote:
> 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).

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.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 3 Jul 11:13
Favicon
Gravatar

Re: Standardizing Firefox's Implementation of Link Fingerprints

"Edward Lee" <edilee <at> mozilla.com> writes:

> 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
Permalink | Reply | 0 comments |
headers
Deventer, M.O. (Oskar) van | 4 Jul 11:35
Picon
Picon
Favicon

ETSI TISPAN interest in tv:URI

All,

The issue of identification of television channels has been discussed in
the ETSI TISPAN 14bis meeting of last week. The application of this
identification is IPTV Presence: a presentity can publish which TV
channel he is watching. The fact that ETSI TISPAN has requirements
related to the identification of TV channels (e.g. tv:URI) is reflected
in the recent update of our internet draft
http://www.ietf.org/internet-drafts/draft-keesmaat-tvreg-01.txt.

TISPAN WG1 (services) and WG2 (architecture) have defined the following
requirements, relevant to our IETF APPS mailing list discussions on the
tv:URI last October.

========== Start of TISPAN requirements ==========

WI01044 (Draft TS 181 016):
"Users' presence information may be related to, e.g., their connection
status, location information, channel currently accessed or acceptable
communication means. Presence information on channel currently accessed
may be used by another user to instruct his set-top box with a single
click to switch to the identified channel, or to instruct his set-top
box to keep following identified channel changes. There may be
significant delays in this following, depending on the update speed of
the presence service.
Any published presence information should only be disseminated other
users that are authorised to receiving this presence information
according to the presentity policies
Users can also define a set of access rules to control access to their
presence information.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Crocker | 6 Jul 19:07

Re: Testers for new ID submission tool


Jeroen Massar wrote:
> Lisa Dusseault wrote:
>> Anybody interested in testing the new ID submission tool?  Russ asked
>> for 10 names, let me know if you're going to be updating a draft or
>> submitting a new draft and I'll pass the first ten names on to Russ.
> 
> Does it accept .xml's ? :)

I don't recall seeing a response to this question.

At this point, I tend to submitt .txt, .pdf and .xml versions together, so 
that the IETF repository has all 3.  I was surprised and quite please to see 
that the PDF version is made public.

So, what does the submission tool accept?

d/

--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply | 5 comments |
headers
Dave Crocker | 6 Jul 19:20
Favicon
Gravatar

Re: Testers for new ID submission tool


Alexey Melnikov wrote:
> It accepts .xml, .pdf and .ps together with .txt. But .txt is required.

Very cool.

The Tool Team Rocks!

d/

--

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
Permalink | Reply | 3 comments |

Gmane