Re: The TLS hammer and resource integrity

On 28 March 2012 05:55, 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.
>
> Mixed content (see Monday's plenary topic) is a good example of where
> TLS doesn't necessarily provide the best trade-off of all the security
> options present.  The classic concern is that I have a TLS-secured
> page that pulls in content over HTTP in the clear.  That unsecured
> content can then potentially poison the entire page.
>
> 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.
>
> 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.
>
> --Martin
>
> long p.s. I should include a reference to the work from decade, that
> deals with exactly this sort of problem in an environment that
> consists entirely of unauthoritative "intermediaries".
>
> 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.

I forgot an important point:

As we develop a more nuanced view of what security means, how we
communicate with users and signal in protocols becomes more relevant.
Showing a lock icon or green/blue address bar has a meaning that users
think that they understand.  For those that pay that much attention,
this is a sign that entering credit card details is OK.

Dealing with communication on these aspects is by no means trivial,
but I don't see it as intractable, just hard.

Received on Wednesday, 28 March 2012 04:14:57 UTC