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

how confident are we that the infrastructure can even handle everyone 
having a cert?

what happens when some script kiddie with a bot net decides to DoS 
ocsp.verisign.com?

I have enough trouble with users complaining about accessing the ocsp 
server for the cert we have already.





------ Original Message ------
From: "Mike Belshe" <mike@belshe.com>
To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Sent: 18/11/2013 11:12:00 a.m.
Subject: Re: something I don't get about the current plan...
>
>
>
>On Sun, Nov 17, 2013 at 9:06 AM, Stephen Farrell 
><stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>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.
>
>We measured this inside Google - its not 100% - but it was pretty good. 
>  Maybe WillChan has those numbers.
>
>
>>
>>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%.
>>
>
>I'm not understanding why they can't get certs?
>
>Do you mean they really can't, or that they just don't want to or 
>believe its too painful?
>
>I agree that the tooling is painful today for TLS.  But I think it will 
>get better if we use more TLS in HTTP/2.
>
>As an example - have you tried being an apple developer?  They make you 
>do all this stuff (get a cert issued, keep it current, etc) to ship a 
>product.  They don't allow random apps without them.  I think a 
>reasonable metaphor can be drawn between a website operator and a apple 
>app developer - both are producing content for a large network of 
>consumers.  Consumers have a reasonable expectation that the content 
>provider has been authenticated in some way, even if not perfect...
>
>There are a million apps in the app store, and every one of them had to 
>go get a cert and keep it up to date.  Why is it harder for the 
>top-1million websites to do this?
>
>Mike
>
>
>
>>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
>> >>>>
>> >>>>
>> >>>
>> >>
>> >
>