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

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

From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Date: Sun, 17 Nov 2013 16:09:46 +0000
Message-ID: <5288EA4A.1080208@cs.tcd.ie>
To: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>

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 16:10:09 UTC

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