Re: The TLS hammer and resource integrity

On Tue, Mar 27, 2012 at 11:55 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> We have already touched on this in discussions of SPDY, but I wanted
> to make a statement on this prior to the meeting on Thursday.
>
> TLS is a great tool in the protocol design toolbox.  It provides a
> great many things together.  Confidentiality, integrity,
> authorization, and so forth.  Therefore, it is very easy to pick up
> that tool and apply it without a complete analysis of the treat model
> and what aspects of that model it addresses.
>
> The property that is required in the mixed content scenario is
> integrity.  The host page might not care that confidentiality is
> maintained when requesting this content, but it really does care that
> the content matches the content that it expects.

I may be misunderstanding, but with Metalink (RFC 6249) we use
Instance Digests (RFC 3230) for integrity, which is a HTTP header
field that includes hashes.

      Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA==
      Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637

we also use the Link header field to provide duplicate locations of
files (on CDNs or mirror networks), digital signatures, and
peer-to-peer info (along with partial file hashes to aid in the repair
of large files).

   Etag: "thvDyvhfIqlvFe+A9MYgxAfm1q5="
   Link: <http://www2.example.com/example.ext>; rel=duplicate
   Link: <ftp://ftp.example.com/example.ext>; rel=duplicate
   Link: <http://example.com/example.ext.torrent>; rel=describedby;
   type="application/x-bittorrent"
   Link: <http://example.com/example.ext.meta4>; rel=describedby;
   type="application/metalink4+xml"
   Link: <http://example.com/example.ext.asc>; rel=describedby;
   type="application/pgp-signature"

> Today, the only option we have available to deal with this problem is
> TLS.  And along with our integrity (and source authentication), we
> also get confidentiality.  This is occasionally desirable, but
> frequently, it is merely consequential.
>
> One significant downside to this arrangement is that confidentiality
> also rules out intermediation options that could be hugely beneficial.
>  Now it is no longer possible to cache copies of JQuery all over the
> web.  (TODO: deal with obvious CDN counter-argument)
>
> Intermediation is a fundamental part of the web architecture and
> building a protocol that makes this inherently difficult would be a
> disservice to the web.
>
> The separation of resource integrity from communication
> integrity/confidentiality is something that I know others have been
> thinking about.  I'd like to see this discussed in HTTP/2.0.
>
> One proposed solution, which should probably be at least considered,
> is to provide a content-specific identifier for a resource.  That is a
> resource is identified by a hash of its representation, so that a
> modified representation can be easily detected.  This might actually
> be more restrictive than is entirely ideal, but it is worth knowing
> about:see draft-farrell-decade-ni.

sounds like a magnet link?

 magnet:?xt=urn:sha1:YNCKHTQCWBTRNJIV4WNAE52SJUQCZO5C

http://en.wikipedia.org/wiki/Magnet_link

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

Received on Wednesday, 28 March 2012 22:36:41 UTC