W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: something I don't get about the current plan...

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sun, 17 Nov 2013 17:06:40 +0000
Message-ID: <5288F7A0.20905@cs.tcd.ie>
To: Mike Belshe <mike@belshe.com>
CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>


On 11/17/2013 04:53 PM, Mike Belshe wrote:
> OK - I see.
> 
> I think you're mixing current stats (only 30% of sites today have certs -
> seems high?) with incompatibilities - 100% of sites can get certs today if
> they want them.  So HTTP/2 requiring certs would not be introducing any
> technical incompatibility (like running on port 100 would).

But 100% of firewalls could open port 100 too.

And saying 100% of sites could get certs ignores the reality
that they do not and nobody so far seems to have a plan to
increase the 30%.

S.


> 
> Mike
> 
> 
> On Sun, Nov 17, 2013 at 8:40 AM, Stephen Farrell
> <stephen.farrell@cs.tcd.ie>wrote:
> 
>>
>>
>> On 11/17/2013 04:36 PM, Mike Belshe wrote:
>>> I'm not 100% sure I read your question right, but I think I get it.
>>>
>>> The difference is between what breaks the server, what breaks in the
>>> client, and what breaks in the middleware.  The middleware is the nasty
>>> stuff that blocks us worst, the two parties that are trying to
>> communicate
>>> (e.g. the client and server) can't fix it.
>>>
>>> So, the 10% failure rate by running non-HTTP/1.1 over port 80 or by
>> running
>>> on port 100 would be because you setup your server properly and the
>>> *client* can't
>>> connect to you because the middleware is broken.
>>>
>>> But ~100% of clients can current connect over port 443, navigate the
>>> middleware, negotiate HTTP/2, and work just fine.
>>
>> But that last isn't true is it if only 30% of sites have certs
>> that chain up to a browser-trusted root, as implied by the
>> reference site. Hence my question.
>>
>> S.
>>
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>
>>> On Sun, Nov 17, 2013 at 8:09 AM, Stephen Farrell
>>> <stephen.farrell@cs.tcd.ie>wrote:
>>>
>>>>
>>>> So the current plan is for server-authenticated https
>>>> everywhere on the public web. If that works, great. But
>>>> I've a serious doubt.
>>>>
>>>> 30% of sites use TLS that chains up to a browser-trusted
>>>> root (says [1]). This plan has nothing whatsoever to say
>>>> (so far) about how that will get to anything higher.
>>>>
>>>> Other aspects of HTTP/2.0 appear to require reaching a
>>>> "99.9% ok" level before being acceptable, e.g. the port
>>>> 80 vs not-80 discussion.
>>>>
>>>> That represents a clear inconsistency in the arguments for
>>>> the current plan. If its not feasible to run on e.g. port
>>>> 100 because of a 10% failure rate, then how is it feasible
>>>> to assume that 60% of sites will do X (for any X, including
>>>> "get a cert"), to get to the same 90% figure which is
>>>> apparently unacceptable, when there's no plan for more-X
>>>> and there's reason to think getting more web sites to do
>>>> this will in fact be very hard at best?
>>>>
>>>> I just don't get that, and the fact that the same people are
>>>> making both arguments seems troubling, what am I missing
>>>> there?
>>>>
>>>> I would love to see a credible answer to this, because I'd
>>>> love to see the set of sites doing TLS server-auth "properly"
>>>> be much higher, but I have not seen anything whatsoever about
>>>> how that might happen so far.
>>>>
>>>> And devices that are not traditional web sites represent a
>>>> maybe even more difficult subset of this problem. Yet the
>>>> answer for the only such example raised (printers, a real
>>>> example) was "use http/1.1" which seems to me to be a bad
>>>> answer, if HTTP/2.0 is really going to succeed HTTP/1.1.
>>>>
>>>> Ta,
>>>> S.
>>>>
>>>> PS: In case its not clear, if there were a credible way to
>>>> get that 30% to 90%+ and address devices, I'd be delighted.
>>>>
>>>> PPS: As I said before, my preference is for option A in
>>>> Mark's set - use opportunistic encryption for http:// URIs
>>>> in HTTP/2.0. So if this issue were a fatal flaw, then I'd
>>>> be arguing we should go to option A and figure out how to
>>>> handle mixed-content for that.
>>>>
>>>> [1] http://w3techs.com/technologies/overview/ssl_certificate/all
>>>>
>>>>
>>>
>>
> 
Received on Sunday, 17 November 2013 17:07:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC