RE: 2 questions

You're skipping the discussion about why price of the cert is not the cost of running TLS.  There's admin overhead in renewing the cert for each domain, there's network infrastructure overhead in providing each domain a unique IP address (because you can't guarantee every client supports SNI, much as we'd like to), and that additional network infrastructure cost means hosting becomes more expensive.  Free certs don't mean free TLS, though obviously they're a nice step in that direction.

But fundamentally, the argument was that if HTTP/2 needed to cover the same scenarios as HTTP/1.1, that set of scenarios included traffic that, by operator choice for whatever reason, is not encrypted.  We're not trying to judge why the operator does it that way, and there will be obvious practical barriers to using HTTP/2 across the internet in plaintext for a while, but the scenario exists and was in-charter, so we continue to support it.  (The same reason we didn't take beneficial-but-breaking changes to Cookies or other semantics, for example.)

-----Original Message-----
From: Walter H. [mailto:Walter.H@mathemainzel.info] 
Sent: Sunday, March 29, 2015 4:35 AM
To: Constantine A. Murenin
Cc: ietf-http-wg@w3.org
Subject: Re: 2 questions

On 29.03.2015 03:19, Constantine A. Murenin wrote:
> On 2015-03-28 7:43, Glen wrote:
>> 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?
>
> This is incorrect.  The cost of certificates for webmasters is not 
> "fairly low or even free".
>
In fact they are fairly low or even free, because nobody tells you 
buying at the most expensive dealer ;-)

just try e.g. StartCom ;-)
> Think of all the consumer electronic devices like the 15 USD 802.11n 
> wireless routers -- who's going to be paying for their certificates?
any cheap routing box, either with WLAN or not does use self-signed 
certificates; and business environments have different use cases and/or 
hardware;
and there they can have their own CA, too ...

> Yes, but mandating a mandatory "https://" address scheme is not a 
> solution.
use TLS with the address scheme "https://", and
>   As has been mentioned, Opportunistic Encryption through the 
> "http://" address scheme is what would help here instead.
not any encryption with the "http://" address scheme;

you don't sell cows as pigs, do you;

Greetings,
Walter

Received on Monday, 30 March 2015 00:50:36 UTC