W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2007

RE: Standardizing Firefox's Implementation of Link Fingerprints

From: Joris Dobbelsteen <Joris@familiedobbelsteen.nl>
Date: Tue, 3 Jul 2007 16:19:49 +0200
Message-ID: <73427AD314CC364C8DF0FFF9C4D693FF037B99@nehemiah.joris2k.local>
To: "Edward Lee" <edilee@mozilla.com>
Cc: <LMM@acm.org>, <ietf-http-wg@w3.org>

>-----Original Message-----
>From: ietf-http-wg-request@w3.org 
>[mailto:ietf-http-wg-request@w3.org] On Behalf Of Larry Masinter
>Sent: dinsdag 3 juli 2007 10:16
>To: 'Edward Lee'
>Cc: ietf-http-wg@w3.org
>Subject: RE: Standardizing Firefox's Implementation of Link 
>The most obvious complaint is that you are usurping the 
>fragment identifier syntax of URIs for a purpose other than 
>what was intended for it.

The most strongest argument against usage.
Exactly as Roy T. Fielding already pointed out.

>Even then, you might have attacks which replace the 
>content-type or other headers in a result. Are you only 
>hashing the content body or the entire HTTP result message?
>It sounds harder to create a Trojan just by supplying a 
>different header, but there might be some circumstances where 
>that would be the case.
>I'm not clear what the threat is that this mechanism is 
>blocking. If someone wants to insert a Trojan, how is it they 
>can do that but not also modify the hash to match the 
>malicious content?


In fact, RFCs are required to have "Security Consideration", which it
has. However this section is saying things regarding 'buffer overflow'
for unobvious reasons (it's a generic problem, not specific to this
RFC). Yet it even fails, IMHO, to address any possible problems with the
scheme (which there are sufficient). In fact, it might miss many of the
practical problems that are presently true for the suggested uses (as
mirrors with immediate pages like cnet and download.com have).

Taking these considerations in general, I do not see how the scheme
provides any added protection in general. A much better way seems the
'signed code' packages, like is currently done with Windows executables
(AuthenticiCode, .NET code signing) and some Linux distrubutions
(package signing with PGP as done with current versions of APT package

As I see it the scheme breaks more standards and fails to solve the
practical problems. In fact, the scheme might also give a completely
false sense of security.

- Joris Dobbelsteen
Received on Tuesday, 3 July 2007 14:23:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:31 UTC