[doseta-discuss] HTTP use cases for DOSETA

[Mark Nottingham]

One other use case. In some circumstances it'd be nice to sign *part* of a header value; e.g., if I have

Forwarded-For: a.b.c.d

and I'm an intermediary who wants to append to it, so we get:

Forwarded-For: a.b.c.d, e.f.g.h

and sign *just* the e.f.g.h part.

I'm not sure if this is a use case for DOSETA, or a separate mechanism.

Cheers,



On 29/04/2011, at 10:58 AM, Mark Nottingham wrote:

> 
> I thought it'd be useful to jot down a few thoughts / references for how HTTP folks might want to use something like DOSETA, to inform the requirements.
> 
> 
> 1. Detecting content changes
> 
> Some folks (often mobile networks, ISPs, "free" internet access providers and enterprises) interpose intercepting proxies that change content; e.g., they insert ads, strip content, transcode content with the intent of making it device-friendly, etc. 
> 
> This concerns browser vendors as well as site operators, as the content isn't being presented as intended, and it's an attack vector.
> 
> By signing responses (including the body and certain headers, e.g., Content-Type), browsers can detect such changes, and either inform the user or refuse to display the content (perhaps based upon configuration).
> 
> To make this workable, sites would need to be able to declare that all of their content is signed, so that hostile intermediaries couldn't overcome the mechanism by simply stripping the signatures. This could be done in DNS or in a HTTPS-hosted well-known URI (RFC5785).
> 
> Potential problems include the overhead of signing responses on-the-fly, and the need to buffer large, dynamic responses to sign them. The latter issue could be overcome by appending the signature in a HTTP trailer (although they can be legitimately stripped, so it's not perfect), or by allowing a signature to NOT sign the body (or only a portion of it) explicitly, so that the response signature is still in place, just incomplete.
> 
> 
> 1a. Verifying caching policy
> 
> Similarly, it's interesting to sign caching-related headers (Date, Cache-Control and Expires) to be able to verify that the server's expressed caching policy has been honoured by any intermediaries. 
> 
> 
> 2. Detecting corruption
> 
> A more pedestrian use case is detecting unintentionally corrupted responses.
> 
> 
> 3. Authenticating the content source
> 
> AIUI Bill Burke's use case is to sign large downloads so that clients (in this case, a software update process) can verify their source, even when hosted on a different server. 
> 
> http://www.ietf.org/id/draft-burke-content-signature-00.txt
> 
> The difference here is that the signature is NOT generated by the server at runtime. 
> 
> 
> 4. Message archiving
> 
> It would be useful in some cases (e.g., legal, archive.org) to be able to archive a HTTP message and use signatures to verify its source. This might include signatures generated both by the origin server and by the archive.
> 
> 
> See also:
>  http://blog.jclark.com/2007/10/http-response-signing-abstract-model.html
>  http://blog.jclark.com/2007/10/http-what-to-sign.html
>  http://blog.jclark.com/2007/10/http-response-signing-strawman.html
> 
> Cheers,
> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 
> _______________________________________________
> doseta-discuss mailing list
> doseta-discuss at trusteddomain.org
> http://www.trusteddomain.org/mailman/listinfo/doseta-discuss

--
Mark Nottingham   http://www.mnot.net/