Re: 2 questions

I can buy that 1/3 of web requests use TLS.

however that does not apply to 1/3 of web sites using TLS.  Probably 
just FB and google alone account for 1/3 of web requests.

There are surely hundreds of millions of sites.  That's at least tens of 
millions of administrators who will need to take on the burden of making 
TLS work on their site.  Many will not see any point in this.  Pretty 
much all the sites that felt a need to deploy TLS will have already done 
so, and the others will not thank the IETF or google or the chromium 
project for attempting to force costs on them.

Please people do not conflate %-age of requests with %-age of sites.

------ Original Message ------
From: "Yoav Nir" <ynir.ietf@gmail.com>
To: "Glen" <glen.84@gmail.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Sent: 29/03/2015 10:32:09 a.m.
Subject: Re: 2 questions

>
>>  On Mar 28, 2015, at 5:43 PM, Glen <glen.84@gmail.com> wrote:
>>
>>  Hi,
>>
>>  I have 2 questions, if I may.
>>
>>  1. What were the reasons for HTTP/2 not requiring TLS?
>>
>>  Is there a significant performance consideration, is it related to 
>>the cost of certificates (which is now fairly low or even free), or 
>>are there other technical reasons?
>>
>>  It would be nice if the web was just "secure by default", and I would 
>>have thought that now would be the right time to move in that 
>>direction.
>>
>>  Also, at least 2 of the major browser vendors have said that they 
>>won't be supporting HTTP/2 without TLS, so surely no one is going to 
>>want to run their website without it?
>
>Right now, about a third of web requests use TLS. Clearly there is a 
>constituency for the web in the clear, although there is a definite 
>trend towards more TLS. If HTTP/2 is supposed to replace HTTP/1 
>entirely, it should support both. Two vendors said they would not 
>support, one said they would. Using the UPGRADE mechanism, an 
>in-the-clear website can support both HTTP/1 and HTTP/2.
>
>As you say, it would be nice if the web was secure by default, but it 
>is not up to you or me to force the web in that direction, or to 
>withhold better performance in HTTP until they fit my definition of 
>“nice”. This is the first rule of the Internet: you are so not in 
>charge.
>
>TLS has a significant cost in processing power, and there are a few 
>cases where its use is inappropriate. Those cases can probably be 
>served nicely by HTTP/1, but we aim to replace HTTP/1.
>
>>  2. Are the BREACH and CRIME exploits still applicable, especially 
>>with regard to content (body) compression? If so, does that mean that 
>>it's not possible to compress content (with gzip, for example) and 
>>still maintain security?
>
>CRIME was specific to retrieving cookie information by having a shared 
>compressed state for resource name (which was under attacker control) 
>and the cookie (which was constant).
>HTTP/2 does not compress headers like that, so this is gone.
>
>BEAST relies on content encryption, and on the attacker being able to 
>inject stuff into the response, discovering pieces of static content 
>such as CSRF tokens. There are ways to foil this attack that worked for 
>HTTP/1, and they should apply similarly to HTTP/2. HTTP/2 itself does 
>nothing to solve this.
>
>HTH
>
>Yoav
>
>

Received on Monday, 30 March 2015 03:17:27 UTC