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

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 16:09:46 +0000

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

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 08:36:29 -0800

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.

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 16:40:10 +0000

> 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.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 08:53:50 -0800

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).

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 17 Nov 2013 17:06:40 +0000

> 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.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Nov 2013 18:10:22 +0100

On 2013-11-17 17:53, 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).
>
> Mike

So we are optimistic that servers can be fixed to use proper certs, but 
pessimistic that bugs in middleware will be fixed?

Best regards, Julian

---

From: Roland Zink <[email-masked]>
Date: Sun, 17 Nov 2013 18:56:37 +0100

I think the argument is that when HTTP2 is deployed by X then X can use 
a proper cert and it will work regardless of the middleware. When 
depending on things being changed in the middle then a HTTP/2 solution 
can't be deployed reliable.

I think

1) this promise will not hold in future and probably is not even true now.
2) Without all clients being HTTP/2 it will be necessary to offer HTTP/2 
and HTTP/1 simultaneously anyway, so is it really a big advantage to 
have the HTTP/2 part be more reliable?
3) If HTTP/2 is a success then bugs in the middleware will be fixed fast
4) Personally I'm pessimistic about the certs, even remembering about 
the expiry date doesn't work for me.
5) Using a separate port would help to separate HTTP/1 and HTTP/2 
infrastructures and will make the solution more reliable

Regards,
Roland

On 17.11.2013 18:10, Julian Reschke wrote:
> So we are optimistic that servers can be fixed to use proper certs, 
> but pessimistic that bugs in middleware will be fixed?
>
> Best regards, Julian
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Mon, 18 Nov 2013 10:24:52 +1300

On 2013-11-18 06:56, Roland Zink wrote:
> I think the argument is that when HTTP2 is deployed by X then X can
> use a proper cert and it will work regardless of the middleware. When
> 2) Without all clients being HTTP/2 it will be necessary to offer
> HTTP/2 and HTTP/1 simultaneously anyway, so is it really a big
> advantage to have the HTTP/2 part be more reliable?

When talking reliability the answer there is yes. The big problem is 
(1), and when that happens (like it does) the trouble of HTTP/2 
implementation starts to be not worth the time adding.

> 3) If HTTP/2 is a success then bugs in the middleware will be fixed 

+1.

> infrastructures and will make the solution more reliable

But *is* somewhat outside charter :

"Retain the semantics of HTTP/1.1, leveraging existing documentation" 
... which all talks about port 80 for HTTP and http://.

"The resulting specification(s) are expected to meet these goals for 
common existing deployments of HTTP; in particular, ...  intermediation 
(by proxies, corporate firewalls, "reverse" proxies and Content Delivery 
Networks)."

... which are today all implemented for port 80.

The use of port 443 is not just about the certs issues. But also about 
reluctance of networks to open port 443 for blind traffic relay. Any new 
port will be facing this battle from scratch as mentioned by others 
already.

>> but pessimistic that bugs in middleware will be fixed?

Not to forget "optimistic that use of other ports will not involve 
middleware bugs" ... including port 443.

Amos

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 22:47:49 +0100

> middleware, negotiate HTTP/2, and work just fine.

No they don't. In fact the number of clients that can do it properly is
abysmally small (last time I tried to write a python script, a couple
months ago, four out of five of the python http framework I tried could
not for example)

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 22:52:42 +0100

> ... which all talks about port 80 for HTTP and http://.

That's playing with words, existing documentation says the protocol is
plain text and that didn't stop anyone from considering binary framing for
http/2

-- 
Nicolas Mailhot

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 14:12:00 -0800

> 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.

> that they do not and nobody so far seems to have a plan to
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

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 17 Nov 2013 23:18:19 +0100

> get a cert and keep it up to date.  Why is it harder for the top-1million

Because you're not designing for the to-1million websites, you're
designing for everyone including people who think green text on pink
background is pretty and don't want their web site go down every year
because their cert expired.

-- 
Nicolas Mailhot

---

From: Bruce Perens <[email-masked]>
Date: Sun, 17 Nov 2013 14:18:38 -0800

On 11/17/2013 02:12 PM, Mike Belshe
wrote:

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?

There is an obvious difference between authentication and encryption
for the purpose of obscuring content. It is not necesary to encrypt
in order to authenticate, only to sign.

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 14:21:43 -0800

> because their cert expired.

No.  This is a change that only affects the servers, not the clients.  The
client UI gets easier when security is on all the time.  I cited those
research reports yesterday.

UI research on mixed mode security has been very clear - we have yet to
find anything that works.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 14:25:02 -0800

On Sun, Nov 17, 2013 at 2:18 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/17/2013 02:12 PM, Mike Belshe wrote:
>
>
>  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?
>
>
> There is an obvious difference between authentication and encryption for
> the purpose of obscuring content. It is not necesary to encrypt in order to
> authenticate, only to sign.
>

Certificates are for server authentication, which we then use to negotiate
encryption.  This is about server auth.

But you took this in a different direction from Stephen's original
question.  He asked whether it was realistic to expect websties to all go
get certificates.

And I'm pointing out that Apple does exactly this for a very large
population of developers.   I believe wholeheartedly that if 1M app
developers can figure out how to get and maintain a cert, so can 1M website
creators.  You have to admit that the top-1M websites and the top-1M apps
have a very high overlap too. :-)

Mike

---

From: Julian Reschke <[email-masked]>
Date: Sun, 17 Nov 2013 23:28:06 +0100

On 2013-11-17 23:12, Mike Belshe wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
> Do you mean they really can't, or that they just don't want to or
> believe its too painful?

There'll always be edge cases like the home router that requires initial 
config to even connect to the internet.

If we don't have a plan for using HTTP/2.0 to connect to these devices, 
then we're not really replacing 1.1. (Reminder: the charter expects us 
to do that).

 > ...

Best regards, Julian

---

From: Roberto Peon <[email-masked]>
Date: Sun, 17 Nov 2013 14:31:41 -0800

The sites have control over their certs, and have complete authority and
ability to change things.
The users have little to no control over middleboxes and have little
ability to change things.
-=R

---

From: Roberto Peon <[email-masked]>
Date: Sun, 17 Nov 2013 14:34:07 -0800

That is fairly sad. I was able to do this with a shell script and 20
seconds of thought the other day.

In any case, I think that Mike was talking about the ability of a properly
implemented endpoint to traverse the internet reliably.
Certainly there may be difficulty in getting a properly implemented
endpoint, but experiences thusfar shows that it isn't unsurmountable given
the wide and successful deployment of HTTPS and various other protocols
over TLS.
-=R

---

From: Bruce Perens <[email-masked]>
Date: Sun, 17 Nov 2013 14:46:50 -0800

On 11/17/2013 02:25 PM, Mike Belshe
wrote:

But you took this in a different direction from
Stephen's original question.  He asked whether it was
realistic to expect websties to all go get certificates.

And I'm pointing out that Apple does exactly this for a
very large population of developers.   I believe
wholeheartedly that if 1M app developers can figure out
how to get and maintain a cert, so can 1M website
creators.  You have to admit that the top-1M websites and
the top-1M apps have a very high overlap too. :-)

We expect applications to have a provable chain of custody because
they exercise control functions on our devices.

We very carefully sandbox programs that are run at the behest of web
pages so that they don't exercise control functions on our devices.

So, the reason for the expectation is very different. And thus no,
it is not realistic to expect the top 1 Million web sites to all be
signed.

Anyway, Apple's rules aren't a public mandate. I visited the
president of Italy once, and he called it "corporate
totalitarianism".

Thanks

Bruce

---

From: Roberto Peon <[email-masked]>
Date: Sun, 17 Nov 2013 14:50:18 -0800

Securing the user<->home-router interaction is mostly orthogonal from using
HTTP or HTTP2.

On the charter thing:
Where does the charter mandate that we must replace HTTP/1.1 in every
use-case?

-=R

On Sun, Nov 17, 2013 at 2:28 PM, Julian Reschke <[email-masked]>wrote:

> then we're not really replacing 1.1. (Reminder: the charter expects us to
> do that).
>
> > ...
>
> Best regards, Julian
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 17 Nov 2013 22:56:05 +0000

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" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>
Cc: "[email-masked] Group" <[email-masked]>
Sent: 18/11/2013 11:12:00 a.m.
Subject: Re: something I don't get about the current plan...
><[email-masked]> wrote:
>>
>>
>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...
>
>> >>> So, the 10% failure rate by running non-HTTP/1.1 over port 80 or 
>>by
>> >> running

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 15:02:29 -0800

On Sun, Nov 17, 2013 at 2:46 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/17/2013 02:25 PM, Mike Belshe wrote:
>
>
>
>   We expect applications to have a provable chain of custody because they
> exercise control functions on our devices.
>

The top-million websites are applications too.  Increasingly we expect more
and more of these websites, and we would like them to work better on small
devices as well.  We would like to be able to tweet a photo from a web app
on our phones.  We would like to be able scan a QR Code from a web page on
our phone.

I see no reason why you would want unauthenticated web apps any more than
you'd want unauthenticated native apps.

But we're traveling off topic from Stephen's question again...

>
> We very carefully sandbox programs that are run at the behest of web pages
> so that they don't exercise control functions on our devices.
>
> So, the reason for the expectation is very different. And thus no, it is
> not realistic to expect the top 1 Million web sites to all be signed.
>
> Anyway, Apple's rules aren't a public mandate. I visited the president of
> Italy once, and he called it "corporate totalitarianism".
>

The point is that cert deployment for the masses is very realistically
doable.   And in fact, it has been done before.  So I don't believe these
arguments that claim that website operators won't be able to do it.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 15:07:15 -0800

> how confident are we that the infrastructure can even handle everyone

100% certain.

> what happens when some script kiddie with a bot net decides to DoS

The same thing that happens when verisign goes down for a few minutes...
 Browsers give the green lights to users (with a few exceptions) because it
would be silly to take down the net just because verisign is down.

http://blog.spiderlabs.com/2011/04/certificate-revocation-behavior-in-modern-browsers.html

Of course, we need to fix this too, even for our existing web.  But the
fact that TLS isn't a panacea doesn't mean that it is useless either.

mike

> On Sun, Nov 17, 2013 at 9:06 AM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
>>
>> -

---

From: "Adrien de Croy" <[email-masked]>
Date: Sun, 17 Nov 2013 23:11:47 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>; "[email-masked] 
Group" <[email-masked]>
Sent: 18/11/2013 12:07:15 p.m.
Subject: Re: something I don't get about the current plan...
>>how confident are we that the infrastructure can even handle everyone 
I wish I shared your certainty there.

>The same thing that happens when verisign goes down for a few 
>minutes...  Browsers give the green lights to users (with a few 
>exceptions) because it would be silly to take down the net just because 
>verisign is down.
browsers may make that decision, but I've seen problems with agents 
barfing because CRL or OCSP servers are unavailable, and so to them, the 
site is effectively down.

So this effectively creates a new central point of failure, which could 
affect millions of sites.

How long will a browser continue to show the site properly while the 
OCSP server is unavailable?  Not forever surely, so if the DoS went on 
and was effective for a long time, the problems would increase?

I think we'd need to fix this, but if we are to alllow revocation of 
certs (which I think is necessary), then there will always be an 
increased infrastructure load as more certs are deployed and sites using 
them are hit.

Adrien

>>>We measured this inside Google - its not 100% - but it was pretty 
>>>good.  Maybe WillChan has those numbers.
>>>
>>>
>>>>
>>>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 
>>>> >>>> [1] 
>>>>http://w3techs.com/technologies/overview/ssl_certificate/all
>>>> >>>>
>>>> >>>>
>>>> >>>
>>>> >>
>>>> >
>>>
>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 18 Nov 2013 00:18:39 +0100

>have a very high overlap too. :-)

Is it necessary to install these Apple developer certificates online on
a shared hosting system? Do these certificates get revoked when a local
user privilege escalation vulnerability is discovered in the operating
system used? What happens when malware is discovered that is designed to
exfiltrate these certificates from developer machines or servers?

Not being able to make apps for computer systems with below 10% market
share is not a great loss, but once web browsers no longer connect to
insecure sites for security reasons, where would dissident groups get
their certificates from? Where would I get one from if I want to inter-
cept what Example Browser is sending to example.com?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bruce Perens <[email-masked]>
Date: Sun, 17 Nov 2013 16:36:01 -0800

On 11/17/2013 03:02 PM, Mike Belshe
wrote:

I see no reason why you would want unauthenticated web
apps any more than you'd want unauthenticated native apps.

The billion instances of Javascript programs run across the web this
morning seem to be contrary to your assumption :-)

Most of those, of course, were trivial little things that controlled
the behavior of some user interface presentation element. They were
carefully constrained by the browser environments that ran them so
that they could not do harm.

Great effort has been put into making these things run quickly and
with a minimum amount of web resources expended. These days, many
web development environments minify javascript and carefully manage
it to be cacheable.

Certainly a class of application that could permanently manipulate
the state of the device running it would need to be signed. I've
helped to manage the chain of custody for Debian. So, I'm not
denying that this is sometimes necessary. Just not for a large class
of trivial things.

Thanks

Bruce

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 15:04:58 +1100

Hi Stephen,

I think that's a great question.

The underlying assumption seems to be that the performance (and other?) benefits of HTTP/2 will lure sites into deploying TLS. Other things could also help, of course -- e.g. better administrator experience in deploying certs on the server, but that's out of scope for us. 

In short, HTTP/2 is being positioned as a gigantic carrot. Because the incentives are lined up (the person who needs to install the cert is getting the benefit of HTTP/2), the theory is that it's not like the other cases.

However, it's still making an assumption that enough people will want those benefits to go through the pain of deploying TLS.

Opportunistic encryption is also a means of addressing this issue; however, there seems to be a lot of doubt about how its introduction would affect the Web, whereas the current approach ("HTTPS Everywhere", to steal a phrase from the EFF) has more well-understood properties.

In the current plan, opp encryption may still have a place, if adoption of HTTP/2-over-TLS-over-HTTPS turns out to be very low.

So, I'd like to hear from those who don't like the current plan; would opp encryption (in a nutshell, HTTP/2 for http:// URIs over TLS without server authentication) help or hurt?

Also, I'm wondering what people (both sides) would think if we allowed http/2 for http:// URLs (with or without opp encryption) for .local and RFC1918 addresses, to ease the IoT / printer cases.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Grahame Grieve <[email-masked]>
Date: Mon, 18 Nov 2013 15:16:05 +1100

> I'm wondering what people (both sides) would think if we allowed http/2 for http:// URLs (with or without opp encryption) for .local and RFC1918 addresses, to ease the IoT / printer cases.

+1. Allow no encryption in these cases

I like encryption everywhere else personally, but would have a problem
if there was no exception for local devices.

Grahame

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 20:19:37 -0800

I'm good with this if, and only if, we also take the step of defining
a separate default port for plaintext http/2 for all other cases.

- James

On Sun, Nov 17, 2013 at 8:04 PM, Mark Nottingham <[email-masked]> wrote:
[snip]

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 15:22:36 +1100

> a separate default port for plaintext http/2 for all other cases.

"all other cases" being...?

At this point in time, I'm looking at this through the lens of <https://github.com/http2/http2-spec/issues/314> -- i.e., what we say, if anything, about browsers on the "open" Web. 

There are a lot of interdependencies on other things, but I'm not sure I get what's motivating this one for you.

Cheers,

P.S. The resolution to that issue *could* come in the form of a separate document, not anything in HTTP/2 itself. E.g., a "how browsers use HTTP" RFC.

---

From: James M Snell <[email-masked]>
Date: Sun, 17 Nov 2013 20:32:03 -0800

> "all other cases" being...?

Addresses other than .local and RFC1918.

- james

> At this point in time, I'm looking at this through the lens of <
https://github.com/http2/http2-spec/issues/314> -- i.e., what we say, if
anything, about browsers on the "open" Web.
> P.S. The resolution to that issue *could* come in the form of a separate
document, not anything in HTTP/2 itself. E.g., a "how browsers use HTTP"
RFC.

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 18 Nov 2013 04:32:49 +0000

there are other cases where encryption is a problem.

One that comes to mind is software updaters.  E.g. if you have an 
updater in your software, which uses http, you might want it to be 
visible what is going on, so that your software can't be accused of 
being spyware when really you're just checking for an update.

It's trivial to demonstrate what is being transmitted if it's plain 
text.  Impossible if not.  These systems commonly use OS-provided 
systems (e.g. WinInet), and work over the internet, so that if the 
mechanism is changed out underneath it would be a problem.

I'm sure there are other systems where openness is a distinct 
requirement.

------ Original Message ------
From: "Mark Nottingham" <[email-masked]>
To: "James M Snell" <[email-masked]>
Cc: "Stephen Farrell" <[email-masked]>; "[email-masked] 
Group" <[email-masked]>
Sent: 18/11/2013 5:22:36 p.m.
Subject: Re: something I don't get about the current plan...
>At this point in time, I'm looking at this through the lens of 
><https://github.com/http2/http2-spec/issues/314> -- i.e., what we say, 
>if anything, about browsers on the "open" Web.
>
>There are a lot of interdependencies on other things, but I'm not sure 
>I get what's motivating this one for you.
>
>Cheers,
>
>
>P.S. The resolution to that issue *could* come in the form of a 
>separate document, not anything in HTTP/2 itself. E.g., a "how browsers 
>use HTTP" RFC.
>
>
>--

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Nov 2013 06:14:03 +0100

> infrastructures and will make the solution more reliable

In theory you're right. In practice it is more difficult to get a new
port working in the short term. While using an existing port immediately
tells you the other part is not willing to upgrade (but will not always
tell you so), another port will require a long timeout to expire before
realizing that the port is closed. Worse, with some SYN-protection
firewalls, the connection will establish but nothing will pass, making
you think the connection to the server was possible and that the server
is slow to respond.

If we were to bother users and have them wait 5 seconds for each site
they want to visit, we could do that. But they're not going to accept
this at all, and even if it only affects a minority it will be an issue
because they'll spread bad words about their last browser upgrade.

BTW it does not affect only browsers. Git has its own port (9418) and
still provides support for fetching over HTTP because it generally passes
firewalls much better. And for the record, even here at home I had to
unlock the port to use it.

And the situation is even worse with mobile phone operators where basically
nothing can pass through unless there's a transparent proxy to handle it,
because the port would remain close until they find the product that do
the MITM...

In fact if we said "in 5 years HTTP/2 will start using port 100", we could
expect that product designers would start supporting it and that by then
most deployed devices would be replaced with something working. But for
many, HTTP/2 is going to be ready tomorrow, not in 5 years.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Nov 2013 06:20:05 +0100

> implemented endpoint to traverse the internet reliably.

I know a number of places (mostly in corporate environments) where you
can't openly access 443 until the site is white-listed. So the benefit
is not on this specific point.

What is interesting however is that most of the time the port is open
to *somewhere*, directly, via an MITM box or via a filtering proxy
which rejects the access. So in almost all cases we can get a quick
response on 443 with a certain confidence. For example, an MITM box
will not blindly advertise HTTP/2.0 with ALPN in the handshake if it
is not aware of this new protocol.

So I'd say that you can trust better what you *see* on port 443 than
what you *see* on 80, which in turn has far more chances of being
opened and respond quickly than a new port, while being less
transparent.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Nov 2013 06:25:57 +0100

On Mon, Nov 18, 2013 at 03:04:58PM +1100, Mark Nottingham wrote:
> Also, I'm wondering what people (both sides) would think if we allowed http/2
> for http:// URLs (with or without opp encryption) for .local and RFC1918
> addresses, to ease the IoT / printer cases.

I like this idea of making an exception for RFC1918 and .local addresses.
We could use the same principle as an exception for accepting to connect
to servers running a self-signed cert and reject it in all other situations
(non .local and non rfc1918).

Willy

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 18 Nov 2013 07:48:25 +0200

> (non .local and non rfc1918).

What's correspondent to RFC1918 on IPv6 side? RFC4193 (yeah, not exact same)?

Also, semantics of .local couple it to single-link DNS-SD. There is now work on
progress with multi-link DNS-SD, which is also local in scope but won't use
.local. 

In fact, MDNSSD might sometimes anchor to names that look global...

Whee, edge cases...

-Ilari

---

From: Mike Belshe <[email-masked]>
Date: Sun, 17 Nov 2013 22:27:27 -0800

On Sun, Nov 17, 2013 at 4:36 PM, Bruce Perens <[email-masked]> wrote:

>  On 11/17/2013 03:02 PM, Mike Belshe wrote:
>
>
>  I see no reason why you would want unauthenticated web apps any more
> than you'd want unauthenticated native apps.
>

No - we don't want them unauthenticated.  We don't want them tampered with.
 Thats just what we're stuck with in http.

>
> Most of those, of course, were trivial little things that controlled the
> behavior of some user interface presentation element. They were carefully
> constrained by the browser environments that ran them so that they could
> not do harm.
>
> Great effort has been put into making these things run quickly and with a
> minimum amount of web resources expended. These days, many web development
> environments minify javascript and carefully manage it to be cacheable.
>

That's what this whole show has been about, we've proven you can make
improvements to HTTP such that we can do security too without losing perf.

>
> Certainly a class of application that could permanently manipulate the
> state of the device running it would need to be signed. I've helped to
> manage the chain of custody for Debian. So, I'm not denying that this is
> sometimes necessary. Just not for a large class of trivial things.
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 18 Nov 2013 08:09:36 +0100

Hi Mark,

There's a bit of calculus that will need to go on for each site.  The
first question might be performance benefit versus cost of encryption. 
That assumes they're (a) not already encrypting and (b) don't have plans
to.  A second question is whether or not encryption poses any other
burdens (such as risk of conflicting algorithm sets).  Also, it will
depend on whether or not crypto reduces access due to blocking.

Eliot

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Nov 2013 09:35:58 +0100

On 2013-11-17 23:50, Roberto Peon wrote:
> Securing the user<->home-router interaction is mostly orthogonal from
> using HTTP or HTTP2.

It is something people do today with 1.1.

Here:

>   It is expected that HTTP/2.0 will:
> ...
>   * Retain the semantics of HTTP/1.1, leveraging existing documentation (see
>     above), including (but not limited to) HTTP methods, status codes, URIs, and
>     where appropriate, header fields.
> ...

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 10:49:54 +0200

> you think the connection to the server was possible and that the server
I disagree. With port 80, you have some chance of sneaking HTTP/2 by the 
firewall, so if HTTP/2 goes to port 100 there will be less HTTP/2 
initially. That is certain.

But there is no need at all for a timeout. Servers already have HTTP/1 
on port 80. They would be able to add HTTP/2 on port 100, so both 
services are available. Port 80 will be used by old clients and clients 
that are stuck behind old middleboxes, whereas port 100 will be used by 
new clients on the open Internet or behind new middleboxes.

A new client would start both connections at the same time. It will only 
give up on one of them after they receive a good reply from the other. 
And by "good reply" I don't mean ACK. I mean an HTTP response with 
actual content. So if all you get on port 80 is a redirect, you keep 
going on both ports until at least one has yielded actual content. This 
is similar to how many platforms do IPv6 vs IPv4, and it adds 
complexity, not latency.

There's no need to keep users waiting.

Yoav

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 18 Nov 2013 10:02:43 +0100

Hi Yoav,

> initially. That is certain.

Huh ? That's what I meant : "it is more difficult to get a new port working
in the short term".

> new clients on the open Internet or behind new middleboxes.

I meant the timeout on the client side! You don't know you're filtered
until you try to escape.

> give up on one of them after they receive a good reply from the other. 

Sending two connections when you need only one is definitely not friendly
to the existing infrastructure. I've already helped people whose server
got knocked down by some browsers' pre-connect features, I can imagine
that doubling the number of connections would not be nice at all...

> actual content.

So you can only do this for idempotent requests then because you'd
possibly send the same request twice. Also in mobile environments
it will be an issue to have to download some objects twice.

> So if all you get on port 80 is a redirect, you keep 

Except that on IPv6 vs IPv4, only TCP connectivity is attempted and
the first one wins, the request is not sent to both servers in parallel.

Willy

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 18 Nov 2013 10:28:35 +0100

Le Lun 18 novembre 2013 01:36, Bruce Perens a écrit :

>  the state of the device running it would need to be signed.

It would need to be more than signed, it would need to use a different
protocol. The sole reason http is widely authorised today, unlike pretty
much any other protocol, is that people think it can not be used to
manipulate the state of their devices.

Any change there would break the security model built around http

Regards,

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 18 Nov 2013 10:32:36 +0100

> cept what Example Browser is sending to example.com?

Moreover it would take about a year before governments stated requiring
CAs to ID their customers just like they did in cybercaffés after the last
run of terrorist attacks. Making the web a registered-only walled garden
is insane.

Regards,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 12:50:16 +0200

> Huh ? That's what I meant : "it is more difficult to get a new port working
Depends on what you mean by "difficult". To me, anything where the user 
gets the resources at either HTTP/1 or HTTP/2 speeds is OK. Having cases 
where the user looks at a blank screen while the browser tries to use 
HTTP/2 when only HTTP/1 is available - that's difficult.
> I meant the timeout on the client side! You don't know you're filtered
You can optimize this the same way browsers detect proxies - you send a 
request to a well-known HTTP/1 + HTTP/2 site, and see which one (or 
both) return.  Then you can try HTTP/1 to the site you really want, and 
if you get an alt-svc header, move to HTTP/2 and cache which sites 
support HTTP/2. This is slightly slower than the happy eyeballs 
approach, and implementers can decide which suits them better.
> that doubling the number of connections would not be nice at all...
Browsers already open several connections in HTTP/1. Opening one for 
each of HTTP/1 and HTTP/2 would not be worse.
> the first one wins, the request is not sent to both servers in parallel.
I kind of agree with that. Clients can make their own policy about 
whether they begin with HTTP/1 and wait for an alt-svc, or they try 
both, or they optimistically try for HTTP/2, and only fall back to 
HTTP/1 if that's not available. The only thing I'm pretty sure of, is 
that trying to mux both protocols on the same port is going to lead to 
more hurt, and specifically, harder-to-fix hurt.

Yoav

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Mon, 18 Nov 2013 12:00:24 +0100

> You can optimize this the same way browsers detect proxies

Or you can actually fix the protocol so proxies can actually declare
themselves and no guessing is needed

Regards,

-- 
Nicolas Mailhot

---

From: Yoav Nir <[email-masked]>
Date: Mon, 18 Nov 2013 13:28:36 +0200

> themselves and no guessing is needed
Hey, if you want to propose a TLS proxy to the IETF, be my guest. I've 
already been burned once trying to do that. Even transparent proxies 
becoming explicit without breaking encryption are not very popular here.

Yoav

http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01

---

From: Patrick McManus <[email-masked]>
Date: Mon, 18 Nov 2013 09:06:36 -0500

On Sun, Nov 17, 2013 at 11:04 PM, Mark Nottingham <[email-masked]> wrote:

>
>
> The underlying assumption seems to be that the performance (and other?)
> benefits of HTTP/2 will lure sites into deploying TLS. Other things could
> also help, of course -- e.g. better administrator experience in deploying
> certs on the server, but that's out of scope for us.
>
> In short, HTTP/2 is being positioned as a gigantic carrot. Because the
> incentives are lined up (the person who needs to install the cert is
> getting the benefit of HTTP/2), the theory is that it's not like the other
> cases.
>
> However, it's still making an assumption that enough people will want
> those benefits to go through the pain of deploying TLS.
>
> Opportunistic encryption is also a means of addressing this issue;
> however, there seems to be a lot of doubt about how its introduction would
> affect the Web, whereas the current approach ("HTTPS Everywhere", to steal
> a phrase from the EFF) has more well-understood properties.
>
> In the current plan, opp encryption may still have a place, if adoption of
> HTTP/2-over-TLS-over-HTTPS turns out to be very low.
>
>
Mark, I think this is a really great summary. Thank you. I will say that
low-adoption isn't necessarily the only possible trigger for me. For my
part, I want to see tls-no-auth vetted by the security folks that I trust
too - and if they are on board then its a lot more attractive to do
proactively. I value their opinions, but it takes some time.

> So, I'd like to hear from those who don't like the current plan; would opp
> encryption (in a nutshell, HTTP/2 for http:// URIs over TLS without
> server authentication) help or hurt?
>
>
both! :)

> Also, I'm wondering what people (both sides) would think if we allowed
> http/2 for http:// URLs (with or without opp encryption) for .local and
> RFC1918 addresses, to ease the IoT / printer cases.
>
>
as above, encryption with no-auth is still a possibility in my mind,
especially for things that don't bootstrap into the PKI well. But no
plaintext at all for me - addresses are meaningless, as is the notion of a
private lan.
http://apps.washingtonpost.com/g/page/world/how-the-nsas-muscular-program-collects-too-much-data-from-yahoo-and-google/543/

---

From: David Morris <[email-masked]>
Date: Mon, 18 Nov 2013 11:41:08 -0800 (PST)

> have a very high overlap too. :-)

I've done both ... iOS developement for multiple entities and obtained and
installed certificates for commercial web sites, company web mail, etc.
I've also gone though the Microsoft code signing process setup.

There are several flaws in any attempt to use Apple's certification
process to support assertions about the ease of obtaining and installing
web server certificates:

a) The Apple process uses a tool and service chain from a single
   vendor and depends on Apple root certificates. Even then it isn't
   trivial. And it gets difficult if the individual has roles involving
   multiple legal entities.

b) I've followed the Apple iOS lists and certificate issues have gotten
   an inordinate amount attention from the difficulties developers have.
   So even with the amount of control Apple has over the process, it
   is difficult.

c) Certificates are relatively expensive. I've supported web sites where
   the whole annual budget was $300. I just handled a certificate renewal
   where the charge was $400 for a 1 year renewal. Cheaper certificates
   are available, but installation then becomes more complex because an
   intermediate certificate is required.

d) iOS developers are probabaly significantly more competent than the
   vast majority of web server administrators. No way are iOS developers
   representative of the technical skill of web server administrators.