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

Re: The TLS hammer and resource integrity

From: Robert Collins <robertc@squid-cache.org>
Date: Thu, 29 Mar 2012 20:49:40 +1300
Message-ID: <CAJ3HoZ1bnmAs=xR-A9SE6ukYNHS5R--pXTx8T2QN0mabfx1U7Q@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Henry Story <henry.story@bblfish.net>, patrick mcmanus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
On Thu, Mar 29, 2012 at 8:20 PM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> In message <0BD7B951-93F7-4620-A098-987EF53E2CA3@bblfish.net>, Henry Story writ
> es:
>
>>You mean the server may not be allowed to use crypto for encryption. I
>>seriously doubt a server may not be allowed to use crypto for integrity and
>>identity. TLS allows crypto to be used for integrity and identity without
>>confidentiality.
>>User interfaces do need to be improved to make this visible, but it is
>>available.
>
> You seem to forget that certain services are based on plausible deniability.
> Adding integrity proving metadata would not work for them.
>
> But at the bottom of this argument is a much more fundamental question
> which you still have not answered:
>
> You and which army is going to make people switch from HTTP/1.1 to
> HTTP/2.0 if they don't think it is an improvement ?
>
> Remember that HTTP/2.0 is an offer we can make, not a law we can enforce.

Its entirely possible as the risks of unencrypted traffic grow, that
jurisdictions will bring in legislation that makes it illegal *not* to
take reasonable steps to protect the personal information of users of
a service. I'd be surprised in fact, if some interpretations of
existing privacy and data protection law wouldn't in fact find
negligence on any service not using TLS.

So, while it is true that *one* factor we have to consider when
assessing *concrete proposals* is whether the proposal as a whole will
be seen as an improvement by *most* HTTP implementors, there is scant
evidence today that either:
 a) requiring TLS would make it 'not an improvement' for most implementors
or
 b) not requiring TLS would make it 'not an improvement' for most implementors.

With the exception of the netflix statement, the only evidence I've
seen put forward here is, frankly hearsay and hyperbole.

We should focus on creating the key criteria we're going to judge the
concrete proposals on. There have been some very good things mentioned
in passing as far as TLS goes:
 - the ability to run an implementation on resource constrained
hardware - sheevaplugs, for instance
 - the ability to have mass market consumer goods, like ADSL gateways,
which roll off a factory line with identical images.
 - the ability for any device on the internet to be a HTTP/2.0 end
point without requiring a central registry (either explicit or
defacto) for such devices.
 - keeping performance in mind: .nz to .uk traffic already pays a high
setup premium for small HTTP objects, making the *overall* user
experience suffer would be a sure way to make HTTP/2.0 unpopular for
many folk.

So, even if we can't agree on TLS/noTLS *today*, can we at least agree
that the criteria above are important - and I'm sure there are many
more such criteria that can be extracted from the conversation so far.

-Rob
Received on Thursday, 29 March 2012 07:50:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:57 GMT