W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: The TLS hammer and resource integrity

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 28 Mar 2012 18:15:01 +1300
To: <ietf-http-wg@w3.org>
Message-ID: <f46d469093a1a7d6a357d77a68217002@treenet.co.nz>
On 28.03.2012 17:14, Martin Thomson wrote:
> On 28 March 2012 05:55, Martin Thomson 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.

All of which is countered with the tiny little fact that said 
green/padlock says nothing about whether the transaction is either 
confidential or private, or going where the user thinks its going. It 
merely says *a* trusted place is connected. Full stop, end of story, 
hand your corporate admin a credit card number to continue.

The amount of trust that users are being taught to place in such 
simplistic arbitrary green/yellow/red colorations far out of sync with 
reality of what they mean.

I completely agree that this needs to be addressed, but the transport 
appears to be doing everything right so far. We have port-443 with 
mandatory TLS. We have Upgrade: to roll out TLS into the unsecured 
areas. We have ubiquitous HTTP middleware capable of receiving and 
sending TLS hop-by-hop or end-to-end as desired. It is the 
implementations which are lagging in support or opting out of using 
security far too often for comfort.

Received on Wednesday, 28 March 2012 05:15:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 October 2015 05:36:50 UTC