[doseta-discuss] HTTP use cases for DOSETA

[Mark Nottingham]

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/