Subject: Re: multiplexing -- don't do it

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 01:57:37 +1200

On 1/04/2012 5:17 a.m., Adam Barth wrote:
> On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham wrote:
>> On 31/03/2012, at 1:11 PM, Mike Belshe wrote:
>>
>>> For the record - nobody wants to avoid using port 80 for new protocols.  I'd love to!  There is no religious reason that we don't - its just that we know, for a fact, that we can't do it without subjecting a non-trivial number of users to hangs, data corruption, and other errors.  You might think its ok for someone else's browser to throw reliability out the window, but nobody at Microsoft, Google, or Mozilla has been willing to do that…
>> Mike -
>>
>> I don't disagree on any specific point (as I think you know), but I would observe that the errors you're talking about can themselves be viewed as transient. I.e., just because they occur in experiments now, doesn't necessarily mean that they won't be fixed in the infrastructure in the future -- especially if they generate a lot of support calls, because they break a lot MORE things than they do now.
>>
>> Yes, there will be a period of pain, but I just wanted to highlight one of the potential differences between deploying a standard and a single-vendor effort.  It's true that we can't go too far here; if we specify a protocol that breaks horribly 50% of the time, it won't get traction. However, if we have a good base population and perhaps a good fallback story, we *can* change things.
> That's not our experience as browser vendors.  If browsers offer an
> HTTP/2.0 that has a bad user experience for 10% of users, then major
> sites (e.g., Twitter) won't adopt it.  They don't want to punish their
> users any more than we do.
>
> Worse, if they do adopt the new protocol, users who have trouble will
> try another browser (e.g., one that doesn't support HTTP/2.0 such as
> IE 9), observe that it works, and blame the first browser for being
> buggy.  The net result is that we lose a user and no pressure is
> exerted on the intermediaries who are causing the problem in the first
> place.
>
> These are powerful market force that can't really be ignored.

So the takeway there is pay attention to the intermediary people when 
they say something cant be implemented (or won't scale reasonably).
With plenty of bias, I agree.

AYJ

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 07:28:30 -0700

On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries <[email-masked]> wrote:

>>>  For the record - nobody wants to avoid using port 80 for new protocols.
>>>>  I'd love to!  There is no religious reason that we don't - its just that
>>>> we know, for a fact, that we can't do it without subjecting a non-trivial
>>>> number of users to hangs, data corruption, and other errors.  You might
>>>> think its ok for someone else's browser to throw reliability out the
>>>> window, but nobody at Microsoft, Google, or Mozilla has been willing to do
>>>> that…
>>>>
>>> Mike -
>>>
>>> I don't disagree on any specific point (as I think you know), but I
>>> would observe that the errors you're talking about can themselves be viewed
>>> as transient. I.e., just because they occur in experiments now, doesn't
>>> necessarily mean that they won't be fixed in the infrastructure in the
>>> future -- especially if they generate a lot of support calls, because they
>>> break a lot MORE things than they do now.
>>>
>>> Yes, there will be a period of pain, but I just wanted to highlight one
>>> of the potential differences between deploying a standard and a
>>> single-vendor effort.  It's true that we can't go too far here; if we
>>> specify a protocol that breaks horribly 50% of the time, it won't get
>>> traction. However, if we have a good base population and perhaps a good
>>> fallback story, we *can* change things.
>>>
> So the takeway there is pay attention to the intermediary people when they
> say something cant be implemented (or won't scale reasonably).
>

I agree we should pay attention to scalability - and we have.

Please don't disregard that Google servers switched to SPDY with zero
additional hardware (the google servers are fully conformant http/1.1
proxies with a lot more DoS logic than the average site).  I know, some
people think Google is some magical place where scalability defies physics
and is not relevant, but this isn't true.  Google is just like every other
site, except much much bigger.   If we had a 10% increase in server load
with SPDY, Google never could have shipped it.  Seriously, who would roll
out thousands of new machines for an experimental protocol?  Nobody.  How
would we have convinced the executive team "this will be faster", if they
were faced with some huge cap-ex bill?  Doesn't sound very convincing, does
it?  In my mind, we have already proven clearly that SPDY scales just fine.

But I'm open to other data.  So if you have a SPDY implementation and want
to comment on the effects on your server, lets hear it!   And I'm not
saying SPDY is free.  But, when you weigh costs (like compression and
framing) against benefits (like 6x fewer connections),  there is no
problem.  And could we make improvements still?  Of course.  But don't
pretend that these are the critical parts of SPDY.  These are the mice nuts.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 02 Apr 2012 14:44:19 +0000

In message <[email-masked]>
, Mike Belshe writes:

>proxies with a lot more DoS logic than the average site).

Google is not typical:

A) Google delivers a very scalable service
B) Google can and has scaled this out to datacenters throughout the globe

Not all users of HTTP can do that.

The benefits you cite, compression of headers and multiplexing of
connections, can also be realized by other protocols, which might be
more generally suitable than SPDY.

But speaking of numbers:  Have Google or anybody else published
numbers for how fast they have managed to get SPDY to run on
contemporary computer hardware ?

How many requests per second ?

How many concurrent connections ?

How many DoS-attacks ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Apr 2012 14:57:16 -0400

On 31/03/2012, at 1:17 PM, Adam Barth wrote:

> On Sat, Mar 31, 2012 at 4:54 AM, Mark Nottingham <[email-masked]> wrote:
>> 

I didn't say bad experience -- we're not talking about breaking Web sites here. If there isn't a good fallback story (as I mentioned), yes, it's obviously a non-starter.

Cheers,

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

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 12:01:41 -0700

On Mon, Apr 2, 2012 at 11:57 AM, Mark Nottingham <[email-masked]> wrote:

> >>> For the record - nobody wants to avoid using port 80 for new
> protocols.  I'd love to!  There is no religious reason that we don't - its
> just that we know, for a fact, that we can't do it without subjecting a
> non-trivial number of users to hangs, data corruption, and other errors.
>  You might think its ok for someone else's browser to throw reliability out
> the window, but nobody at Microsoft, Google, or Mozilla has been willing to
> do that…
> >>
> >> Mike -
> >>
> I didn't say bad experience -- we're not talking about breaking Web sites
> here. If there isn't a good fallback story (as I mentioned), yes, it's
> obviously a non-starter.
>

I think you guys are saying the same thing...  when these errors occur, the
browser incurs a hang or undetected content corruption.  That gets
manifested to the user in a way for which there is either no fallback
(corruption undetected) or for which there is a horrible hang and the
fallback occurs 30+ seconds later...

I'm betting we all agree these are both unacceptable.

Mike

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 20:43:53 +0000

------ Original Message ------
From: "Mike Belshe" [email-masked]
>    protocols.  I'd love to!  There is no religious reason that we 
>    don't - its just that we know, for a fact, that we can't do it 
>    without subjecting a non-trivial number of users to hangs, data 
>    corruption, and other errors.  You might think its ok for someone 
>    else's browser to throw reliability out the window, but nobody at 
>    Microsoft, Google, or Mozilla has been willing to do that…
    Mike -
    
    I don't disagree on any specific point (as I think you know), but I 
    would observe that the errors you're talking about can themselves 
    be viewed as transient. I.e., just because they occur in 
    experiments now, doesn't necessarily mean that they won't be fixed 
    in the infrastructure in the future -- especially if they generate 
    a lot of support calls, because they break a lot MORE things than 
    they do now.
    
    Yes, there will be a period of pain, but I just wanted to highlight 
    one of the potential differences between deploying a standard and a 
    single-vendor effort.  It's true that we can't go too far here; if 
    we specify a protocol that breaks horribly 50% of the time, it 
    won't get traction. However, if we have a good base population and 
    perhaps a good fallback story, we *can* change things.
   That's not our experience as browser vendors.  If browsers offer an
   HTTP/2.0 that has a bad user experience for 10% of users, then major
   sites (e.g., Twitter) won't adopt it.  They don't want to punish 
   their
   users any more than we do.
   
   exerted on the intermediaries who are causing the problem in the 
   first
   place.

 
 
 Please don't disregard that Google servers switched to SPDY with zero 
 additional hardware (the google servers are fully conformant http/1.1 
 proxies with a lot more DoS logic than the average site).  I know, 
 some people think Google is some magical place where scalability 
 defies physics and is not relevant, but this isn't true.  Google is 
 just like every other site, except much much bigger.   If we had a 10% 
 increase in server load with SPDY, Google never could have shipped it. 
  Seriously, who would roll out thousands of new machines for an 
 experimental protocol?  Nobody.  How would we have convinced the 
 executive team "this will be faster", if they were faced with some 
 huge cap-ex bill?  Doesn't sound very convincing, does it?  In my 
 mind, we have already proven clearly that SPDY scales just fine.
 
 But I'm open to other data.  So if you have a SPDY implementation and 
 want to comment on the effects on your server, lets hear it!   And I'm 
 not saying SPDY is free.  But, when you weigh costs (like compression 
 and framing) against benefits (like 6x fewer connections),  there is 
 no problem.  And could we make improvements still?  Of course.  But 
 don't pretend that these are the critical parts of SPDY.  These are 
 the mice nuts.
  
For a forward proxy, there are several main reasons to even exist:
  
a) implement and enforce access control policy
b) audit usage
c) cache
  
you block any of these by bypassing everything with TLS, you have a 
non-starter for corporate environments.  Even if currently admins kinda 
turn a blind eye (because they have to) and allow port 443 through, as 
more and more traffic moves over to 443, more pressure will come down 
from management to control it.
  
Best we don't get left with the only option being MITM.
  
Adrien

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 13:52:22 -0700

On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy <[email-masked]> wrote:

> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries < <[email-masked]>
> [email-masked]> wrote:
>
> turn a blind eye (because they have to) and allow port 443 through, as more
> and more traffic moves over to 443, more pressure will come down from
> management to control it.
>

In my talk at the IETF, I proposed a solution to this.

Browsers need to implement SSL to trusted proxies, which can do all of the
a/b/c that you suggested above.  This solution is better because the proxy
becomes explicit rather than implicit.  This means that the user knows of
it, and it IT guys knows of it.  If there are problems, it can be
configured out of the system.  Implicit proxies are only known the the IT
guy (maybe), and can't be configured out from a client.  The browser can be
made to honor HSTS so that end-to-end encryption is always enforced
appropriately.

Further, proxies today already need this solution, even without SPDY.
 Traffic is moving to SSL already, albeit slowly, and corporate firewalls
can't see it today.  Corporate firewall admins are forced to do things like
block facebook entirely to prevent data leakage.  But, with this solution,
they could allow facebook access and still protect their IP.  (Or they
could block it if they wanted to, of course).

Anyway, I do agree with you that we need better solutions so that we don't
incur more SSL MITM.  Many corporations are already looking for expensive
SSL MITM solutions (very complex to rollout due to key management) because
of the reasons I mention above, and its a technically inferior solution.

So lets do it!

Mike

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 21:08:07 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 3/04/2012 8:52:22 a.m.
Subject: Re: multiplexing -- don't do it
> >    corruption, and other errors.  You might think its ok for 
> >    someone else's browser to throw reliability out the window, but 
> >    nobody at Microsoft, Google, or Mozilla has been willing to do 
> >    that…
 >    Mike -
 >    
 >    I don't disagree on any specific point (as I think you know), but 
 >    I would observe that the errors you're talking about can 
 >    themselves be viewed as transient. I.e., just because they occur 
 >    in experiments now, doesn't necessarily mean that they won't be 
 >    fixed in the infrastructure in the future -- especially if they 
 >    generate a lot of support calls, because they break a lot MORE 
 >    things than they do now.
 >    
 >    Yes, there will be a period of pain, but I just wanted to 
 >    highlight one of the potential differences between deploying a 
 >    standard and a single-vendor effort.  It's true that we can't go 
 >    too far here; if we specify a protocol that breaks horribly 50% 
 >    of the time, it won't get traction. However, if we have a good 
 >    base population and perhaps a good fallback story, we *can* 
 >    change things.
    
    So the takeway there is pay attention to the intermediary people 
    when they say something cant be implemented (or won't scale 
    reasonably).

   Please don't disregard that Google servers switched to SPDY with 
   zero additional hardware (the google servers are fully conformant 
   http/1.1 proxies with a lot more DoS logic than the average site).  
   I know, some people think Google is some magical place where 
   scalability defies physics and is not relevant, but this isn't true. 
    Google is just like every other site, except much much bigger.   If 
   we had a 10% increase in server load with SPDY, Google never could 
   have shipped it.  Seriously, who would roll out thousands of new 
   machines for an experimental protocol?  Nobody.  How would we have 
   convinced the executive team "this will be faster", if they were 
   faced with some huge cap-ex bill?  Doesn't sound very convincing, 
   does it?  In my mind, we have already proven clearly that SPDY 
   scales just fine.
   
   But I'm open to other data.  So if you have a SPDY implementation 
   and want to comment on the effects on your server, lets hear it!   
   And I'm not saying SPDY is free.  But, when you weigh costs (like 
   compression and framing) against benefits (like 6x fewer 
   connections),  there is no problem.  And could we make improvements 
   still?  Of course.  But don't pretend that these are the critical 
   parts of SPDY.  These are the mice nuts.

   
  you block any of these by bypassing everything with TLS, you have a 
  non-starter for corporate environments.  Even if currently admins 
  kinda turn a blind eye (because they have to) and allow port 443 
  through, as more and more traffic moves over to 443, more pressure 
  will come down from management to control it.

 
 Browsers need to implement SSL to trusted proxies, which can do all of 
 the a/b/c that you suggested above.  This solution is better because 
 the proxy becomes explicit rather than implicit.  This means that the 
 user knows of it, and it IT guys knows of it.  If there are problems, 
 it can be configured out of the system.  Implicit proxies are only 
 known the the IT guy (maybe), and can't be configured out from a 
 client.  The browser can be made to honor HSTS so that end-to-end 
 encryption is always enforced appropriately.
 
 Further, proxies today already need this solution, even without SPDY.  
 Traffic is moving to SSL already, albeit slowly, and corporate 
 firewalls can't see it today.  Corporate firewall admins are forced to 
 do things like block facebook entirely to prevent data leakage.  But, 
 with this solution, they could allow facebook access and still protect 
 their IP.  (Or they could block it if they wanted to, of course).
 
 Anyway, I do agree with you that we need better solutions so that we 
 don't incur more SSL MITM.  Many corporations are already looking for 
 expensive SSL MITM solutions (very complex to rollout due to key 
 management) because of the reasons I mention above, and its a 
 technically inferior solution.
 
 So lets do it!
  
I basically agree with all the above, however there is the ISP 
intercepting proxy to think about.
  
Many ISPs here in NZ have them, it's just a fact of life when you're 
150ms from the US and restricted bandwidth.  Pretty much all the big 
ISPs have intercepting caching proxies.
  
There's just no way to make these work... period...
  
unless the ISP is to
  
a) try and support all their customers to use an explicit proxy, or
b) get all their customers to install a root cert so they can do MITM.
  
Maybe we need a better way to force a client to use a proxy, and take 
the pain out of it for administration.  And do it securely (just 
remembering why 305 was deprecated).
  
Adrien

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 14:11:26 -0700

On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de Croy <[email-masked]> wrote:

> Cc: "Amos Jeffries" <[email-masked]>;"[email-masked]" <
> [email-masked]>
> On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy < <[email-masked]>
> [email-masked]> wrote:
>
>>
>> From: "Mike Belshe" <[email-masked]>[email-masked]
>>
>>
>>
>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries < <[email-masked]><[email-masked]>
>> want to comment on the effects on your server, lets hear it!   And I'm not
> Many ISPs here in NZ have them, it's just a fact of life when you're 150ms
> from the US and restricted bandwidth.  Pretty much all the big ISPs have
> intercepting caching proxies.
>

> Maybe we need a better way to force a client to use a proxy, and take the
> pain out of it for administration.  And do it securely (just remembering
> why 305 was deprecated).
>

Do proxy pacs or dhcp work for this?

Note that we also need the browsers to honor HSTS end-to-end, even if we
turn on "GET https://".
Mike

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 2 Apr 2012 17:15:20 -0400

" Further, proxies today already need this solution, even without SPDY.
 Traffic is moving to SSL already, albeit slowly, and corporate firewalls
can't see it today.  Corporate firewall admins are forced to do things like
block facebook entirely to prevent data leakage.  But, with this solution,
they could allow facebook access and still protect their IP.  (Or they
could block it if they wanted to, of course). "

I don't understand how your HTTPS proxy will fix this since facebook itself
will still be HTTPS. So with your proxy its SSL in SSL tunnel.

The proxy can still not see the facebook traffic in the clear so the admin
will still either need to block facebook entirely or do a MITM.

Peter

On Mon, Apr 2, 2012 at 5:11 PM, Mike Belshe <[email-masked]> wrote:

>> the a/b/c that you suggested above.  This solution is better because the
>> proxy becomes explicit rather than implicit.  This means that the user
>> knows of it, and it IT guys knows of it.  If there are problems, it can be
>> management) because of the reasons I mention above, and its a technically
>> inferior solution.
>>
>> So lets do it!
>>
>>
>> 150ms from the US and restricted bandwidth.  Pretty much all the big ISPs
>> have intercepting caching proxies.
>>

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 14:20:51 -0700

On Mon, Apr 2, 2012 at 2:15 PM, Peter Lepeska <[email-masked]> wrote:

> I don't understand how your HTTPS proxy will fix this since facebook
> itself will still be HTTPS. So with your proxy its SSL in SSL tunnel.
>

I was trying to describe https to the proxy, which breaks the SSL, and then
initiates a new SSL connection to FB.

I call this a "trusted proxy".  The browser in this case must have
explicitly specified the proxy to use and also that it is okay to let it
break SSL.

Mike

>> On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de Croy <[email-masked]>wrote:
>>
>>>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 21:24:28 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Amos Jeffries" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 3/04/2012 9:11:26 a.m.
Subject: Re: multiplexing -- don't do it

I don't know - MS may be able to shed some light there?  I would have 
thought it was considered risky to auto config a proxy outside your LAN.
  
>
>Note that we also need the browsers to honor HSTS end-to-end, even if 
>we turn on "GET https://".
Actually a bigger concern is client certificates.
  
I can't think of a reliable / secure way to get these to work if there 
is an intermediary.  The server would need to trust the intermediary to 
pass on the client cert somehow, and also trust it to not mess with the 
data. I don't see how that sort of trust could be established easily.

One of the main reasons I'm keen to add GET https:// is to enable 
further locking down of CONNECT.
  
CONNECT is currently a can of worms.  Providing good granular control 
is difficult, since you only have server:port to play with.  I think 
any proposal for GET https:// should also:
  
a) propose a mechanism to bounce a CONNECT request with a status 
telling the client to use GET https:// instead
b) maybe some sort of advertised OPTION in the proxy
c) config on the client to allow this, and therefore also support for 
auto config mechanisms (PAC would need to distinguish between current 
https rules, which result in CONNECT vs some new rule that results in 
GET https://)
  
This would allow our customers to basically lock down CONNECT or turn 
it off completely.

Adrien

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Apr 2012 22:36:32 +0100

> explicitly specified the proxy to use and also that it is okay to let it

TLS MITM has been proposed before and rejected.

Even for FB, but definitely for banking, I don't want that middlebox
getting my re-usable credentials and I don't see how to avoid that
problem.

I do understand that there are percieved-real requirements here
for enterprise middleboxes to snoop but we've not gotten IETF
consensus to support that kind of feature in our protocols.

Stephen.

PS: I'm not angling for better http auth here. Even if we get that
there will be many passwords and other re-usable credentials in use
for pretty much ever and the argument against breaking TLS will
remain.

>> On Mon, Apr 2, 2012 at 5:11 PM, Mike Belshe<[email-masked]>  wrote:
>>
>>>
>>>
>>> On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de Croy<[email-masked]>wrote:
>>>
>>>>
>>>> From: "Mike Belshe"<[email-masked]>
>>>> To: "Adrien W. de Croy"<[email-masked]>
>>>> Cc: "Amos Jeffries"<[email-masked]>;"[email-masked]"<
>>>> [email-masked]>
>>>> On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy<  <[email-masked]>
>>>> [email-masked]>  wrote:
>>>>
>>>>>
>>>>> From: "Mike Belshe"<[email-masked]>[email-masked]
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries<  <[email-masked]><[email-masked]>

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 14:38:30 -0700

> b) get all their customers to install a root cert so they can do MITM.

solution a) sounds reasonably easy, no? The alternative is that everyone
doing any SSL to ANYWHERE is strongly disincented, even today.
The user in these cases would be incented to do the right thing because it
makes things faster for them. I'm not seeing where the problem is here.

> pain out of it for administration.  And do it securely (just remembering

like normal proxy configuration?

Assuming proxies were not explicit, what do you propose the users do the
ISP begins filtering and censoring content for reasons of greed?
-=R

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 21:43:10 +0000

------ Original Message ------
From: "Stephen Farrell" <[email-masked]>
To: "Mike Belshe" <[email-masked]>
Cc: "Peter Lepeska" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 3/04/2012 9:36:32 a.m.
Subject: breaking TLS (Was: Re: multiplexing -- don't do it)
>TLS MITM has been proposed before and rejected. 
I don't think that's what Mike was proposing when he said break.
  
the proposal is that TLS would terminate on the proxy, then the client 
would additionally / optionally be able to specify that the proxy make 
an SSL connection to the server.
  
It's all explicit, no MITM, no underhandedness.
  
>getting my re-usable credentials and I don't see how to avoid that 
  
You're right, the proxy would still get this, which is why it would 
need to be trusted.  There's no other way.
  
This issue won't be going away.  Unless you think you can convince 
every boss/parent on the planet that their employees/kids should be 
able to do whatever they like.
>consensus to support that kind of feature in our protocols. 
  
sure we do.  2616 already contemplates and supports proxies - just not 
with https.  
  
>for pretty much ever and the argument against breaking TLS will 
  
Auth in fact may be the answer to the issue of trust for a server to 
place in a proxy (re the client cert issue).
  
There may not be a good answer for client certs, and it may be the only 
way to support them is to continue to tunnel.
  
At least they are not that prevalent so that in cases where they are 
required, tunneling can be allowed.
  
Adrien
>>>>>>On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries< 
>>>>>><[email-masked]><[email-masked]> 
>>>>>>>>>>don't - its 
>>>>>>>>>highlight 
>>>>>>>when 
>>>>>>zero 
>>>>>>some 
>>>>>>and 
>>>>>>kinda 
>>>>>firewalls

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 14:43:41 -0700

> consensus to support that kind of feature in our protocols.

You can "MITM" tcp instead of at the plaintext layer too.
The choice should be up to the user-- they choose to use an explicit proxy
The alternative is for them to send everything in the clear.

Note as well that you're probably conflating "runs over TLS" for "the user
requested trust+security", which isn't necessarily the case here.
The intent is to make it so that all queries run over a TLS channel, even
when there is no expectation for trust.. because that is far, far better
than just doing it in the clear at your internet cafe.

Those with an expectation of trust should probably not allow the MITM for
the HTTPS content, unless there is no choice (which is effectively the case
today as well, since blocking :443 is trivial).

-=R

>>>> On Mon, Apr 2, 2012 at 2:08 PM, Adrien W. de Croy<[email-masked]
>>>> >wrote:
>>>>
>>>>
>>>>> Cc: "Amos Jeffries"<[email-masked]**>;"[email-masked]"<
>>>>> [email-masked]>
>>>>>> From: "Mike Belshe"<[email-masked]>mike@**belshe.com<[email-masked]>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries<  <[email-masked]
>>>>>> ><squid3@**treenet.co.nz <[email-masked]>>
>>>>>>>>> be viewed
>>>>>>>>> we
>>>>> the

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 21:48:08 +0000

------ Original Message ------
From: "Roberto Peon" [email-masked]

you ever worked on an ISP support desk?

These are people who can hardly use a mouse you're trying to get them 
to set up proxy config in their browser?
  
>
>Assuming proxies were not explicit, what do you propose the users do 
>the ISP begins filtering and censoring content for reasons of greed?
>-=R 
> 
More likely due to statutory requirements.  You guys may think you 
dodged a bullet with SOPA... other countries you wouldn't expect have 
already passed laws requiring censorship by ISPs   
  
It's not an issue that's going away either.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 14:59:52 -0700

> you ever worked on an ISP support desk?

Umm, actually I have.

>
> These are people who can hardly use a mouse you're trying to get them to
> set up proxy config in their browser?
>
>

I'm familiar with these kinds of people and working with them. I'd imagine
that the ISP would give them an installer which would find and set config
for these programs without the user having to do it themselves or something
similarly easy.

> More likely due to statutory requirements.  You guys may think you dodged
> a bullet with SOPA... other countries you wouldn't expect have already
> passed laws requiring censorship by ISPs
>

You're assuming that the ISP's incentives align with the user? I don't. I
imagine there are some out there who do and are, but on the whole, if
the capability to make more money exists from installing a box that does
something to the user's traffic, I'd expect that it gets done.
Off the top of my head, they can inspect what is going on and sell the data
of people's behaviors. You could also degrade the service quality for any
site that was in competition with any that your company (or affiliate)
provided. Note well that these have already happened. This is NOT
theoretical.

-=R

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 15:02:56 -0700

I don't trust proxies... hopefully that is apparent, but I'm asking for
explicit support for them and attempting to deny support for non explicit
proxies.
On a related point, I'd like to see content signed so that when it is
munged, it is detectable. This helps to change the trust game because it
allows a site to specify (without possibility of modification) policy to
the UA about the fetching of further resources, even through an explicit
proxy.

-=R

On Mon, Apr 2, 2012 at 2:59 PM, Roberto Peon <[email-masked]> wrote:

> Off the top of my head, they can inspect what is going on and sell the
> data of people's behaviors. You could also degrade the service quality for
> any site that was in competition with any that your company (or affiliate)

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 2 Apr 2012 18:04:48 -0400

On 02/04/2012, at 5:48 PM, Adrien W. de Croy wrote:

> These are people who can hardly use a mouse you're trying to get them to set up proxy config in their browser?

I've been convinced for a long time that we need to improve both proxy.pac and wpad if we want to get rid of interception proxies.

Incomplete issues list:
  - no way to specify timeouts (for a request, for a connection to a proxy, between read()s, etc.)
  - no way to control retry behaviour
  - visibility into cache errors, with control over how they're handled
  - limited view of connection state 
  - no visibility into cache availability (up/down, ping times)
  - need more sophisticated load balancing (right now it has to be kludged)

Regards,

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 02 Apr 2012 23:06:08 +0100

On 04/02/2012 10:43 PM, Adrien W. de Croy wrote:
>>> I was trying to describe https to the proxy, which breaks the SSL,
>>> and then initiates a new SSL connection to FB.
>>> explicitly specified the proxy to use and also that it is okay to let
>>> it break SSL.
>>

Previous proposals were also explicit and open yet didn't achieve
IETF consensus. If this "feature" is to be designed-in, I predict
it'll be quite controversial. You can argue that the IETF hasn't
been good with this and with NAT (i.e. middleboxen in general) but
that's probably because there are real arguments against such
things, as well as for them.

> You're right, the proxy would still get this, which is why it would need
> to be trusted. There's no other way.

Just saying "trusted" not sufficient - trusted for what?

If you were to describe this as "trusting your employer with your
bank account credentials" then it might be more accurate, and, yes,
less acceptable.

> This issue won't be going away. Unless you think you can convince every
> boss/parent on the planet that their employees/kids should be able to do
> whatever they like.

I agree there's an issue there. OTOH, is there good evidence of the
effectiveness of such outbound proxies in terms of their claimed
benefits?

I also don't buy that most users will know enough to say "ah,
www-proxy.example.com:8080 is ok" esp. when the browser discovered
the proxy who know's how.

Stephen.

>>
>>
>> I do understand that there are percieved-real requirements here for
>> enterprise middleboxes to snoop but we've not gotten IETF consensus to
>> support that kind of feature in our protocols.
>
>> for pretty much ever and the argument against breaking TLS will remain.
>
>>>> The proxy can still not see the facebook traffic in the clear so the
>>>> admin will still either need to block facebook entirely or do a MITM.
>>>> Peter
>>>>>> ------ Original Message ------ From: "Mike
>>>>>> Belshe"<[email-masked]> To: "Adrien W. de Croy"<[email-masked]>
>>>>>> [email-masked]> Sent: 3/04/2012 8:52:22 a.m. Subject: Re:
>>>>>> multiplexing -- don't do it
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 2, 2012 at 1:43 PM, Adrien W. de Croy<
>>>>>> <[email-masked]> [email-masked]> wrote:
>>>>>>>
>>>>>>> ------ Original Message ------ From: "Mike
>>>>>>> Belshe"<[email-masked]>[email-masked]
>>>>>>>
>>>>>>>
>>>>>>>>>>> don't - its just that we know, for a fact, that we can't do
>>>>>>>>>>> it without subjecting a non-trivial number of users to hangs,
>>>>>>>>>>> data corruption, and other errors. You might think its ok for
>>>>>>>>>>> someone else's browser to throw reliability out the window,
>>>>>>>>>>> but nobody at Microsoft, Google, or Mozilla has been willing
>>>>>>>>>>> to do that…
>>>>>>>>>> Mike -
>>>>>>>>>> I don't disagree on any specific point (as I think you know),
>>>>>>>>>> but I would observe that the errors you're talking about can
>>>>>>>>>> themselves be viewed as transient. I.e., just because they
>>>>>>>>>> occur in experiments now, doesn't necessarily mean that they
>>>>>>>>>> won't be fixed in the infrastructure in the future --
>>>>>>>>>> especially if they generate a lot of support calls, because
>>>>>>>>>> they break a lot MORE things than they do now.
>>>>>>>>>> standard and a single-vendor effort. It's true that we can't
>>>>>>>>>> go too far here; if we specify a protocol that breaks horribly
>>>>>>>>>> 50% of the time, it won't get traction. However, if we have a
>>>>>>>>>> good base population and perhaps a good fallback story, we
>>>>>>>>>> *can* change things.
>>>>>>>>> That's not our experience as browser vendors. If browsers offer
>>>>>>>>> an HTTP/2.0 that has a bad user experience for 10% of users,
>>>>>>>>> then major sites (e.g., Twitter) won't adopt it. They don't
>>>>>>>>> want to punish their users any more than we do.
>>>>>>>>> Worse, if they do adopt the new protocol, users who have
>>>>>>>>> trouble will try another browser (e.g., one that doesn't
>>>>>>>>> support HTTP/2.0 such as IE 9), observe that it works, and
>>>>>>>>> blame the first browser for being buggy. The net result is that
>>>>>>>>> we lose a user and no pressure is exerted on the intermediaries
>>>>>>>>> who are causing the problem in the first place.
>>>>>>> http/1.1 proxies with a lot more DoS logic than the average
>>>>>>> site). I know, some people think Google is some magical place
>>>>>>> where scalability defies physics and is not relevant, but this
>>>>>>> isn't true. Google is just like every other site, except much
>>>>>>> much bigger. If we had a 10% increase in server load with SPDY,
>>>>>>> Google never could have shipped it. Seriously, who would roll out
>>>>>>> thousands of new machines for an experimental protocol? Nobody.
>>>>>>> How would we have convinced the executive team "this will be
>>>>>>> faster", if they were faced with some huge cap-ex bill? Doesn't
>>>>>>> sound very convincing, does it? In my mind, we have already
>>>>>>> proven clearly that SPDY scales just fine.
>>>>>>> a) implement and enforce access control policy b) audit usage c)
>>>>>>> cache
>>>>>>> you block any of these by bypassing everything with TLS, you have
>>>>>>> a non-starter for corporate environments. Even if currently
>>>>>>> admins kinda turn a blind eye (because they have to) and allow
>>>>>>> port 443 through, as more and more traffic moves over to 443,
>>>>>>> more pressure will come down from management to control it.
>>>>>> Browsers need to implement SSL to trusted proxies, which can do
>>>>>> all of the a/b/c that you suggested above. This solution is better
>>>>>> because the proxy becomes explicit rather than implicit. This
>>>>>> means that the user knows of it, and it IT guys knows of it. If
>>>>>> there are problems, it can be configured out of the system.
>>>>>> Implicit proxies are only known the the IT guy (maybe), and can't
>>>>>> be configured out from a client. The browser can be made to honor
>>>>>> HSTS so that end-to-end encryption is always enforced appropriately.
>>>>>> Further, proxies today already need this solution, even without
>>>>>> SPDY. Traffic is moving to SSL already, albeit slowly, and
>>>>>> corporate firewalls can't see it today. Corporate firewall admins
>>>>>> are forced to do things like block facebook entirely to prevent
>>>>>> data leakage. But, with this solution, they could allow facebook
>>>>>> access and still protect their IP. (Or they could block it if they
>>>>>> wanted to, of course).
>>>>>> Anyway, I do agree with you that we need better solutions so that
>>>>>> we don't incur more SSL MITM. Many corporations are already
>>>>>> looking for expensive SSL MITM solutions (very complex to rollout
>>>>>> due to key management) because of the reasons I mention above, and
>>>>>> its a technically inferior solution.
>>>>>> So lets do it!
>>>>>>
>>>>>> Many ISPs here in NZ have them, it's just a fact of life when
>>>>>> you're 150ms from the US and restricted bandwidth. Pretty much all
>>>>>> the big ISPs have intercepting caching proxies.
>>>>>> a) try and support all their customers to use an explicit proxy,
>>>>>> or b) get all their customers to install a root cert so they can
>>>>>> do MITM.
>>>>>
>>>>>
>>>>>> Maybe we need a better way to force a client to use a proxy, and
>>>>>> take the pain out of it for administration. And do it securely
>>>>>> (just remembering why 305 was deprecated).
>>>>>
>>>>> Note that we also need the browsers to honor HSTS end-to-end, even
>>>>> if we turn on "GET https://". Mike
>>>>>
>>>>>
>>>>>
>>>>>> Adrien
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> Adrien
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>

---

From: J Ross Nicoll <[email-masked]>
Date: Mon, 02 Apr 2012 23:10:04 +0100

On 02/04/2012 22:59, Roberto Peon wrote:

>
>     These are people who can hardly use a mouse you're trying to get
>     them to set up proxy config in their browser?
>
>
> I'm familiar with these kinds of people and working with them. I'd 
> imagine that the ISP would give them an installer which would find and 
> set config for these programs without the user having to do it 
> themselves or something similarly easy.

Probably, but if proxy information could be added into DHCP, DNS or 
similar, isn't that going to be a lot more straight-forward than 
everyone having to provide their own installers through a separate 
distribution channel?

If a proxy can intercept secure traffic, that needs to be made really 
clear to the user (especially in cases such as those "FREE INTERNET!!!" 
ad-hoc networks that turn up in airports and similar), but that's 
presumably something for the browser peeps to figure out.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 2 Apr 2012 15:21:00 -0700

And the server/content provider folk as well-- both client and site
participate in policy setting (and for good reasons on both sides).
-=R

On Mon, Apr 2, 2012 at 3:10 PM, J Ross Nicoll <[email-masked]> wrote:

> imagine that the ISP would give them an installer which would find and set
> config for these programs without the user having to do it themselves or
> something similarly easy.
>
>
> similar, isn't that going to be a lot more straight-forward than everyone
> having to provide their own installers through a separate distribution
> channel?
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 22:23:31 +0000

------ Original Message ------
 
 Umm, actually I have. 

  
I'm a bit out of touch on that count... last time I remember dealing 
with that, ISPs were sending out disks with Navigator on it.
  
But it only masks the issue in a bunch of cases.  People still download 
and install another browser.  In the end, unless the OS and browsers do 
a great job of co-operating over such config, it can still rear it's 
head.
  
I'd be quite keen for some more work to be done on the auto discovery 
and config option, since it could save a lot of work in customer sites 
(there is already AD group policy, but not everyone has that or can 
figure it out).
  
>You're assuming that the ISP's incentives align with the user? 
I sure don't.
  
>I don't. I imagine there are some out there who do and are, but on the 
>whole, if the capability to make more money exists from installing a 
>box that does something to the user's traffic, I'd expect that it gets 
>done. 
>data of people's behaviors. You could also degrade the service quality 
>for any site that was in competition with any that your company (or 
>affiliate) provided. Note well that these have already happened. This 
>is NOT theoretical.
  
that would be illegal I think in some countries.  The issue would be 
detecting it.  I don't know how TLS would ameliorate that anyway (if 
that's where you're heading).
  
Adrien

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 22:28:01 +0000

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Mike Belshe" <[email-masked]>;"Amos Jeffries" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 3/04/2012 10:02:56 a.m.
Subject: Re: multiplexing -- don't do it
>I don't trust proxies... hopefully that is apparent, but I'm asking 
>for explicit support for them and attempting to deny support for non 
>explicit proxies. 
I don't have a problem with proxy usage moving to explicit only.  We've 
been trying to get customers to move in that direction for years.
  
Customers do like using interception though.  Educating them costs 
money.  Not providing the feature would cost us sales, until we could 
get commitment from every other vendor to deprecate the feature.
  
if 2.0 can fix this by providing a path forward which doesn't allow it, 
then everyone will be in the same boat, which is fine with me.
  
>munged, it is detectable. This helps to change the trust game because 
>it allows a site to specify (without possibility of modification) 
>policy to the UA about the fetching of further resources, even through 
>an explicit proxy.
  
I think there will still be cases where trusting a proxy will be 
required.  In the end, if you use it, it can do anything.  If your 
browser sends any request to it over SSL, then the opportunity for 
decisions based on trust are pretty much gone already.
  
Adrien
  
  I'm familiar with these kinds of people and working with them. I'd 
  imagine that the ISP would give them an installer which would find 
  and set config for these programs without the user having to do it 
  themselves or something similarly easy.
   
   >
   >Assuming proxies were not explicit, what do you propose the users 
   >do the ISP begins filtering and censoring content for reasons of 
   >greed?
   >-=R 
   > 
  >dodged a bullet with SOPA... other countries you wouldn't expect 
  >have already passed laws requiring censorship by ISPs   
  > 
 >You're assuming that the ISP's incentives align with the user? I 
 >don't. I imagine there are some out there who do and are, but on the 
 >box that does something to the user's traffic, I'd expect that it 
 >gets done. 
 >Off the top of my head, they can inspect what is going on and sell 
 >the data of people's behaviors. You could also degrade the service 
 >quality for any site that was in competition with any that your 
 >company (or affiliate) provided. Note well that these have already 
 >happened. This is NOT theoretical.
 >
 >-=R
 > 
 >  
 > > 
 >
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 22:34:45 +0000

------ Original Message ------
>things, as well as for them. 
  
I don't disagree.
  
>bank account credentials" then it might be more accurate, and, yes, 
It's difficult to quantify.
  
In the end, it's trust in the vendor of the software not to put 
something nasty in.
  
We already do that with pretty much all software we run.
  
And then it's trust in whoever may get access to confidential 
information not to do anything untoward with it, whatever that is.
  
We already do that all the time as well.  With your bank, your 
government etc.
>>every 
  
you're asking if there's any evidence that implementing acceptable use 
policies has any merit?
  
that's a political issue.  
>the proxy who know's how. 
Definitely. There's a real issue there.  Hence my comment about doing 
any discovery in a secure (holistically) manner.
  
Adrien

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 15:36:57 -0700

On Mon, Apr 2, 2012 at 3:28 PM, Adrien W. de Croy <[email-masked]> wrote:

> Cc: "Mike Belshe" <[email-masked]>;"Amos Jeffries" <[email-masked]
> >;"[email-masked]" <[email-masked]>
> Customers do like using interception though.  Educating them costs money.
> Not providing the feature would cost us sales, until we could get
> commitment from every other vendor to deprecate the feature.
>

If we got SSL interception to work with trusted proxies, it would be a huge
feature to a lot of corporate sites. Not having to roll out SSL MITM is
really valuable to them.

I'm 100% sure that Chrome & Firefox would get behind a solution which
enforced SSL more often and required browsers to support more features with
trusted SSL to proxies.

Mike

> required.  In the end, if you use it, it can do anything.  If your browser
> sends any request to it over SSL, then the opportunity for decisions based
> on trust are pretty much gone already.
>
> Adrien
>
>
> -=R
>
> On Mon, Apr 2, 2012 at 2:59 PM, Roberto Peon < <[email-masked]>
> [email-masked]> wrote:
>
>>
>>
>>  On Mon, Apr 2, 2012 at 2:48 PM, Adrien W. de Croy < <[email-masked]>
>> [email-masked]> wrote:
>>
>>>
>>> From: "Roberto Peon" <[email-masked]>[email-masked]
>>>
>>>
>>>
>>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 00:38:12 +0200

> then everyone will be in the same boat, which is fine with me.

Hypothetically speaking, if HTTP/2.0 were TLS only, then either vendors
would have to move to explicit proxies or to SSL MITM...

---

From: Mike Belshe <[email-masked]>
Date: Mon, 2 Apr 2012 15:43:50 -0700

On Mon, Apr 2, 2012 at 3:06 PM, Stephen Farrell
<[email-masked]>wrote:

>> Cc: "Peter Lepeska" <[email-masked]>;"[email-masked]<[email-masked]>
>> "
>> <[email-masked]>

The alternative is SSL MITM - where the corp IT guy now just has to go hack
a bunch of CA stuff into his environment to trick his users and their
browsers.  Is this really better?  Do we want this as our future?  Or would
a more explicit and controlled environment be better?

I don't disagree with your concerns, of course.  This work needs a lot of
scrutiny.  But I do think we can improve overall SSL adoption if we
recognize what people are going to do without these types of features.

Mike

>>>>>>>> Belshe"<[email-masked]>mike@**belshe.com <[email-masked]>
>>>>>>>>
>>>>>>>>
>>>>>>>> <[email-masked]><squid3@**treenet.co.nz<[email-masked]>
>>>>>>>> >

---

From: Robert Collins <[email-masked]>
Date: Tue, 3 Apr 2012 11:04:08 +1200

> would have to move to explicit proxies or to SSL MITM...

You say 'move to', but the reality has been for years that vendors
*have* SSL MITM up and running. Hell, a CA was busted a month or so
back for issuing wildcard certs (top level wildcard no less!) to
organisations that wanted to MITM all their traffic... nevermind that
they could then issue a cert for *any* domain which would be in
default browsers cert list...

SSL MITM isn't something we need to work hard to *avoid*, its
something we have to deal with today.

The best we can do is setup an environment where there is less or even
no need for SSL MITM, where folk that are doing SSL MITM today can
migrate to something a little less toxic tomorrow.

-Rob

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 00:06:32 +0100

Shortening a bit...

> a more explicit and controlled environment be better?

False dichotomy anyone? ;-)

Is it clear that the corp IT guy is really benefiting from the MITM? I'm
not saying they are not benefiting, but I've not seen the evidence.

There is plenty of evidence that people sell this kind of thing and that
people use this kind of thing, but if its trivially defeated we're into
security theatre.

If that were the case, then maybe e2e security isn't worth giving
up for so little.

> recognize what people are going to do without these types of features.

The problem is, scrutiny will not enable us to square a circle, which
may be what's involved here.

S

>>>>>>>>> Belshe"<[email-masked]>mike@**belshe.com<[email-masked]>
>>>>>>>>>
>>>>>>>>>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 23:11:07 +0000

------ Original Message ------
From: "Robert Collins" <[email-masked]>
To: "William Chan (陈智昌)" <[email-masked]>
Cc: "Adrien W. de Croy" <[email-masked]>;"Roberto Peon" 
<[email-masked]>;"Mike Belshe" <[email-masked]>;"Amos Jeffries" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 3/04/2012 11:04:08 a.m.
Subject: Re: multiplexing -- don't do it
>migrate to something a little less toxic tomorrow.

completely agree.  
  
MITM is a PITA for vendors, you have to ship your signing cert, and 
real-time generate spoofed signed certs to fool the browsers.
  
So providing explicit support would make life a fair bit easier.  I'm 
pretty sure everyone who wrote MITM was holding their nose at the time.
  
Adrien

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:12:31 +0200

> not saying they are not benefiting, but I've not seen the evidence.

Sorry, I'm tired and sleepy, but I don't see what's not obvious about this.
Yes, the IT guy is benefiting. He's able to implement organizational policy
(e.g.: prevent leakage of corporate secrets or preventing students from
browsing pr0n) by doing SSL MITM.

> people use this kind of thing, but if its trivially defeated we're into

I'm not sure what you mean by "trivially defeated", but if you mean whether
or not SSL is subverted by these MITM boxes, then it's obvious that this is
already the case. See
https://www.corelan.be/index.php/2012/03/14/blackhat-eu-2012-day-1/ for
example. The SSL MITM proxy did not do any certificate validation.

>>>>>>>>> Cc: "Amos Jeffries"<[email-masked]****>;"[email-masked]
>>>>>>>>> "<
>>>>>>>>>
>>>>>>>>>> Belshe"<[email-masked]>mike@****belshe.com<[email-masked]>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> <[email-masked]><squid3@****treenet.co.nz<squid3@**
>>>>>>>>>> treenet.co.nz <[email-masked]>>
>>>>>>>>>>
>>>>>>>>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:15:26 +0200

> migrate to something a little less toxic tomorrow.

Not sure if you were suggesting I disagreed in any way :) I agree, which is
why we should push forward an explicit proxy solution, which is IMO far
less toxic.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 02 Apr 2012 23:18:03 +0000

------ Original Message ------
From: "Adrien W. de Croy" <[email-masked]>
>real-time generate spoofed signed certs to fool the browsers. 
  
sorry, when I say "ship", I mean install a cert (e.g. self-signed 
generated on the proxy, not shipped from the vendor) onto all client 
computers.
  
Adrien

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 02 Apr 2012 19:21:35 -0400

> pretty sure everyone who wrote MITM was holding their nose at the time.

++yes, and we could probably also provide a mechanism for signing 
content e2e so the end user can still verify with the normal pki whether 
or not the integrity assertion of the resources match the host in the uris.

I'm as firm on TLS-everywhere as anyone, but I recognize in some 
situations the user will need to consent to a non e2e version. Informed 
consent with reasonable granularity (Will's mention that CONNECT or 
block-me is still appropriate for a subset of things) is critical here, 
as is the elimination of passive attacks. That is still a massive win 
for privacy. The framework for consent needs work, and things like wpad 
probably need a new looking over. Undeniably hard stuff.

We've got time for all of that if we're pointed in roughly the same 
direction.

-P

---

From: Robert Collins <[email-masked]>
Date: Tue, 3 Apr 2012 11:22:59 +1200

This seems rather timely:

http://www.telegraph.co.uk/technology/news/9179087/Internet-activity-to-be-monitored-under-new-laws.html

-Rob

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:27:36 +0200

On Tue, Apr 3, 2012 at 1:21 AM, patrick mcmanus <[email-masked]>wrote:

> ++yes, and we could probably also provide a mechanism for signing content
> e2e so the end user can still verify with the normal pki whether or not the
> integrity assertion of the resources match the host in the uris.
>
> block-me is still appropriate for a subset of things) is critical here, as
> is the elimination of passive attacks. That is still a massive win for
> privacy. The framework for consent needs work, and things like wpad

Maybe I'm misreading the direction of the conversation, but I'm actually
pretty excited here since people seem to be agreeing that we should try to
provide a better path (explicit trusted HTTPS proxies) than lame SSL MITM
proxies. These problems with deciding between end to end or GET
https://and integrity checks on trusted HTTPS proxies served content
are difficult
to solve, but I think it's tractable and very worthy of more brainstorming
/ discussion.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 00:28:04 +0100

> Sorry, I'm tired and sleepy, but I don't see what's not obvious about this.

Maybe I'm dense. Its not obvious to me.

> browsing pr0n) by doing SSL MITM.

You really mean "prevent" there? POSTing a rot13 version of the
corporate secret won't work? And I thought more anti-porn policies
were domain name and not content based.

If there's published evidence of the effectiveness of that kind of
thing I've not seen it, but I didn't go looking. Saying its obvious
doesn't help me at least.

I can more easily envisage spotting malware on the inbound side
as maybe effective but don't know how much of that is coming
via TLS.

Really, I'm asking for evidence here, not just trying to score
points.

S.

>>>>>>>>>>> treenet.co.nz<[email-masked]>>
>>>>>>>>>>>
>>>>>>>>>>>

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 11:30:04 +1200

On 03.04.2012 09:11, Mike Belshe wrote:
>>> On Mon, Apr 2, 2012 at 6:57 AM, Amos Jeffries < 
>>>>>> but I
>>>>> an
>> SPDY.
>> don't
>> 150ms
>> take the

For browsers, when WPAD is setup in the network and the browser 
shipping with default auto-configuration. Yes. For all other situations, 
not so much.

Unfortunately several major browsers still ship with "no proxy" as 
their default, meaning the WPAD does not work for 10-20% of users. On 
top of that WPAD is still a non-standard mess not supported by 
non-browser agents, and admin are understandably very reluctant to do 
the little bit of extra work without a great deal of need. Admin who do 
make the jump toward auto-conf simplicity are forced to add MITM 
underneath anyway.

AYJ

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 00:30:35 +0100

> http://www.telegraph.co.uk/technology/news/9179087/Internet-activity-to-be-monitored-under-new-laws.html

And not timely but relevant:

http://tools.ietf.org/html/rfc2804

S

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 11:47:28 +1200

On 03.04.2012 10:36, Mike Belshe wrote:
> On Mon, Apr 2, 2012 at 3:28 PM, Adrien W. de Croy wrote:
>
>>
>> From: "Roberto Peon"
>> for
>> money.

The 8+ years we have had bugs open against Firefox explaining the 
use-cases, what is needed and even describing potential configuration 
specs say otherwise.
Instead admin are forced to rollout a Firefox proxy config plugin which 
almost but not quite works, and these days both of them breaks for a few 
weeks out of each month.

Me and hundreds of other admin annoyed? yes. Meanwhile we have MITM, 
and countless others don't even bother to voice their opinions about it, 
just jump straight to MITM.

AYJ

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:47:31 +0200

On Tue, Apr 3, 2012 at 1:28 AM, Stephen Farrell
<[email-masked]>wrote:

>> <[email-masked]>**wrote:
>>
>>
>>> Shortening a bit...
>>>
>>>

I don't mean _completely_ prevent. But help stop the 9X% case? Yeah, I
think that's what they're shooting for. I'm not well versed in the
intricacies of IT policies using these SSL MITM proxies (I suspect someone
else on the mailing list is), but I know there are schools and what not
which want to filter based on content, since schools want this from Google
(see http://support.google.com/websearch/bin/answer.py?hl=en&answer=173733).

>> https://www.corelan.be/index.**php/2012/03/14/blackhat-eu-**2012-day-1/<https://www.corelan.be/index.php/2012/03/14/blackhat-eu-2012-day-1/>for
>>>>>>>>>>> Cc: "Amos Jeffries"<[email-masked]******>;"
>>>>>>>>>>> [email-masked]
>>>>>>>>>>>
>>>>>>>>>>> "<
>>>>>>>>>>>
>>>>>>>>>>>> Belshe"<[email-masked]>mike@******belshe.com<[email-masked]>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> <[email-masked]><squid3@******treenet.co.nz<squid3@**
>>>>>>>>>>>>
>>>>>>>>>>>> treenet.co.nz<squid3@treenet.**co.nz <[email-masked]>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>>>  That's not our experience as browser vendors. If browsers
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> offer

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 00:54:19 +0100

On 04/03/2012 12:47 AM, William Chan (陈智昌) wrote:

> intricacies of IT policies using these SSL MITM proxies

Me neither. That's why I asked. But I'd like to know not
just about the policy they want to (or pay to) enforce,
but rather also about the effectiveness of their attempts
at enforcement.

S

 > (I suspect someone
>>>>>>>>>>>>> treenet.co.nz<squid3@treenet.**co.nz<[email-masked]>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 3 Apr 2012 01:55:24 +0200

On Tue, Apr 3, 2012 at 1:47 AM, Amos Jeffries <[email-masked]> wrote:

> use-cases, what is needed and even describing potential configuration specs
> say otherwise.

I can't speak for Firefox (Pat?), but what Mike said definitely applies to
Chrome. We already have HTTPS proxy support. Are there other features you'd
like us to add on this front?

> Me and hundreds of other admin annoyed? yes. Meanwhile we have MITM, and
> countless others don't even bother to voice their opinions about it, just
> jump straight to MITM.
>
> AYJ
>
>

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 02 Apr 2012 20:07:48 -0400

On 4/2/2012 7:55 PM, William Chan (???) wrote:
> On Tue, Apr 3, 2012 at 1:47 AM, Amos Jeffries <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>     use-cases, what is needed and even describing potential
>     configuration specs say otherwise.
>     Instead admin are forced to rollout a Firefox proxy config plugin
>     which almost but not quite works, and these days both of them
>     breaks for a few weeks out of each month.
>
>
If we build a strong definition of this stuff around HTTP/2 that will 
clearly be a priority and I feel confident in saying firefox will 
support that.

If you're interested in HTTPS proxy support before that I think we need 
to figure out how to fully bake the "don't proxy my bank session" use 
case in a way that is better than just letting the admin supplied wpad 
script make the decision. When not in a HTTP/2 context that's really 
outside the scope of httpbis though - feel free to write me directly if 
you want to pursue it.

-P

---

From: Amos Jeffries <[email-masked]>
Date: Tue, 03 Apr 2012 12:19:00 +1200

> but rather also about the effectiveness of their attempts

IME admin are usually not that eager to do MITM on TLS. It is required 
by policy makers who just want to publish tick-box policies about the 
things they can prevent, HTTPS just being one of many policy evasions to 
be worked around. Collateral damage and accuracy is not so important as 
having the ability to be vocal about it and tick off that security 
checkbox without being caught lying.

AYJ

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 03 Apr 2012 00:27:05 +0000

------ Original Message ------
>but rather also about the effectiveness of their attempts 
  
That's more of a political issue.  Same with police and laws.  
Something doesn't need to be 100% effective in order to be pursued.
  
But the malware case is definitely an issue, if the entire web goes to 
SSL, then 100% of web-borne malware will be over SSL.
  
Browser hijacking etc will not go away with this either.
  
I really can't see the entire web going SSL/TLS though.  Maybe we need 
to bang heads a bit more on this issue :)
  
>>(see 
>>http://support.google.com/websearch/bin/answer.py?hl=en&answer=173733). 
>>
>>
>>
>>>>or not SSL is subverted by these MITM boxes, then it's obvious that 
>>>>this 
>>>>is 
>>>>already the case. See 
>>>>>  I don't disagree with your concerns, of course. This work needs 
>>>>>a lot 
>>>>>of 
>>>>>
>>>>>>>>>enterprise middleboxes to snoop but we've not gotten IETF 
>>>>>>>>>consensus 
>>>>>>>>>to 
>>>>>>>>>  sure we do. 2616 already contemplates and supports proxies - 
>>>>>>>>>just 
>>>>>>>>not 
>>>>>>>>with https. 
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Stephen. 
>>>>>>>>There may not be a good answer for client certs, and it may be 
>>>>>>>>the 
>>>>>>>>only 
>>>>>>>>>>  The proxy can still not see the facebook traffic in the 
>>>>>>>>>>clear so 
>>>>>>>>>>the 
>>>>>>>>>>
>>>>>>>>>>>admin will still either need to block facebook entirely or 
>>>>>>>>>>>do a 
>>>>>>>>>>>MITM. 
>>>>>>>>>>>Peter 
>>>>>>>>>>>>>>>>>>it without subjecting a non-trivial number of users 
>>>>>>>>>>>>>>>>>>to 
>>>>>>>>>>>>>>>>>>hangs, 
>>>>>>>>>>>>>>>>>>data corruption, and other errors. You might think 
>>>>>>>>>>>>>>>>>>its ok 
>>>>>>>>>>>>>>>>>>for 
>>>>>>>>>>>>>>>>>highlight one of the potential differences between 
>>>>>>>>>>>>>>>>>deploying 
>>>>>>>>>>>>>>>>>a 
>>>>>>>>>>>>>>>>blame the first browser for being buggy. The net result 
>>>>>>>>>>>>>>>>is 
>>>>>>>>>>>>>>>>that 
>>>>>>>>>>>>>>>>  So the takeway there is pay attention to the 
>>>>>>>>>>>>>>>>intermediary 
>>>>>>>>>>>>>>>people 
>>>>>>>>>>>>>>Google never could have shipped it. Seriously, who would 
>>>>>>>>>>>>>>roll 
>>>>>>>>>>>>>>out 
>>>>>>>>>>>>>>For a forward proxy, there are several main reasons to 
>>>>>>>>>>>>>>even 
>>>>>>>>>>>>>>exist: 
>>>>>>>>>>>>>>you block any of these by bypassing everything with TLS, 
>>>>>>>>>>>>>>you 
>>>>>>>>>>>>>>have 
>>>>>>>>>>>>>all of the a/b/c that you suggested above. This solution 
>>>>>>>>>>>>>is 
>>>>>>>>>>>>>better 
>>>>>>>>>>>>>access and still protect their IP. (Or they could block it 
>>>>>>>>>>>>>if 
>>>>>>>>>>>>>they 
>>>>>>>>>>>>>wanted to, of course). 
>>>>>>>>>>>>>due to key management) because of the reasons I mention 
>>>>>>>>>>>>>above, 
>>>>>>>>>>>>>and 
>>>>>>>>>>>>>you're 150ms from the US and restricted bandwidth. Pretty 
>>>>>>>>>>>>>much 
>>>>>>>>>>>>>all

---

From: Martin Thomson <[email-masked]>
Date: Tue, 3 Apr 2012 02:34:06 +0200

On 3 April 2012 01:28, Stephen Farrell <[email-masked]> wrote:
> corporate secret won't work?

I think that we should be clear in separating the _desire_ to do
something from the effectiveness of a particular measure in achieving
the (desired) end.

I've encountered a policy that blocked a popular online document
sharing/editing site.  Ostensibly, this was to prevent the leakage of
confidential information.  This particular measure was both more
effective in preventing real work than it was in its stated goal; more
convenient methods for disseminating secrets at the same time were
completely unaddressed.

That is, "the hole in the fence we can live with, but the tunneling
under the walls must stop!"

That does not mean that the specific policy rule was not considered
highly desirable by policy-makers.

I suspect that, at the root of all this, is a desperate attempt by
administrators to retain some sort of control.  The fact is that the
way that we communicate on the web is vastly more complex than their
policy engine is capable of managing.  Adding real time communications
only complicates that further.

The quick and easy solution to the realtime communications mess is
blocking UDP.  My guess is that this is what we'll get.  Controlling
this is going to be quite complex.  That said, with a lot of work, I
can see how sites might be selectively allowed onto a whitelist.

--Martin

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 03 Apr 2012 01:55:46 +0000

------ Original Message ------
>http://tools.ietf.org/html/rfc2804 

OK, thanks for pointing that out.
  
We are at a slightly different juncture than we were in 2000.
  
It seems to me, the issue of mandatory SSL is far from put to rest.
  
In relation to RFC2804, it's one thing to take a position of not taking 
a position, which is fine and completely reasonable.
  
It's another to promote a protocol that explicitly goes against the 
wishes of governments, and therefore creates problems for implementors, 
potentially criminalises users and implementors.  Thats doesn't equate 
to not taking a position.
  
Even if we put wiretapping issues aside, there are plenty of other 
reasons why it's IMO unfeasible to make SSL/TLS mandatory, and these 
relate mainly to administrative, security, and infrastructural issues.  
  
We simply are not at a place where deployment of SSL certificates 
beyond the realms of technically proficient operators is feasible to 
support.
  
We don't have a viable deployable alternative to certificates.  
Shared-secret is not viable for the web at large.
  
We are also not at a place where we've solved the issues relating to 
certificate verification. OCSP servers are a highly central point of 
failure (with enormous consequences) and go down. 
  
We didn't even touch on deployability of TLS/SSL into tiny footprints, 
or the non-zero costs in terms of latency and CPU / RAM at various 
points in the network.
Arguments about users right for privacy are political arguments, and 
fall afoul of RFC 2804 on the other side.
  
Corporates also have a right and an increasing requirement to know what 
their resources are being used for.  This requirement is getting 
stronger not weaker, as countries around the world roll out laws around 
internet copyright abuse.  For instance in NZ, there's a 3 strike 
system now, with large fines etc.  Companies need to be able to protect 
themselves from liability for their users' actions.

I don't really have much more on the topic of mandatory-to-use SSL.  In 
the end, if that's where the specs go, we are just escalating the arms 
race, which simply incurs cost on the users of these protocols, for 
which history may not thank us.  We'll just have all the pain of 
everyone having to deploy SSL, and we'll get MITM as well.
Cheers
Adrien

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 03:12:58 +0100

> We are at a slightly different juncture than we were in 2000.

Sure.

> potentially criminalises users and implementors. Thats doesn't equate to
> not taking a position.

I think you're missing some context. In ~1999 the US government exerted
serious pressure to get the IETF to add a law enforcement field to
protocols that'd allow for key escrow.

After an extended debate involving many, many IETF folks, we said no.
That was explicitly going against the government of the country from
which most IETF participants originate.

IMO this doesn't speak to whether or not to mandate use of TLS, but
rather is only really relevant to the MITM-like features discussed
recently here, and maybe only when considering government actions.

S

> We simply are not at a place where deployment of SSL certificates beyond
> the realms of technically proficient operators is feasible to support.
>
> their resources are being used for. This requirement is getting stronger
> not weaker, as countries around the world roll out laws around internet
> copyright abuse. For instance in NZ, there's a 3 strike system now, with
> large fines etc. Companies need to be able to protect themselves from
> liability for their users' actions.
>
> which history may not thank us. We'll just have all the pain of everyone
> having to deploy SSL, and we'll get MITM as well.
> Cheers
> Adrien
>
>
>>
>> S
>>> -Rob
>>>
>>
>
>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Tue, 03 Apr 2012 02:34:55 +0000

------ Original Message ------
>recently here, and maybe only when considering government actions. 
  
OK.  At the end of the day, governments have other options.
  
They can pass laws, and prosecute software vendors and users.  They can 
develop their own protocols which comply with their laws.
  
they don't need the IETF to condone them.
  
I hate to think what a really hard-line regime would do.  They could 
push the line pretty hard.
I'm not saying this as a justification for wiretapping.  In fact I'm 
not really interested in the wiretapping issue so much.  I agree with 
the reasons for not allowing it, especially where the conclusion (IMO 
rightly) is reached that it actually reduces security for all.
  
I also believe however that mandatory crypto would reduce its 
effectiveness for all, due to the IMO inevitable problems that would 
come with deploying it on such a massive scale, so we may end up with 
reduced security in the places we currently really need it.
  
Adrien

>>beyond 
>>stronger 
>>everyone

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 3 Apr 2012 08:31:46 +0200

Hi Martin,

> can see how sites might be selectively allowed onto a whitelist.

You know, I have several customers where the only way to look outside is
to pass through a proxy, that's fairly common, especially in companies
which run on non-rfc1918 addresses. At these places, it's very simple :

  - port 80  => URL classification + content inspection
  - port 443 => destination must match a short whitelist of allowed domains
    that are directly related to employees' job

And I'm seeing this becoming more and more common because it's simple and
efficient to apply the web policies that managers want. In fact the first goal
is not to ensure there is no data leak, the first goal is to try to protect
the PCs against malware as much as possible by limiting their access to what
they really need, because infected PCs cost *a lot* to an enterprise by
preventing people from doing their job. Of course there is also the goal to
avoid the temptation of entertainment. If people want to browse unfiltered,
they do it with their smartphones and it's their problem.

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Tue, 3 Apr 2012 08:32:07 +0200

On Tue, Apr 3, 2012 at 1:30 AM, Stephen Farrell
<[email-masked]>wrote:

>> http://www.telegraph.co.uk/**technology/news/9179087/**
>> Internet-activity-to-be-**monitored-under-new-laws.html<http://www.telegraph.co.uk/technology/news/9179087/Internet-activity-to-be-monitored-under-new-laws.html>
>>
>
> http://tools.ietf.org/html/**rfc2804 <http://tools.ietf.org/html/rfc2804>

So from my reading of this, what we're discussing as a https trusted proxy
does not classify under RFC 2804's definition of wiretapping in any way.

Section 3 defines 4 definitions of wiretapping, and we are not hitting any
of them:

1) Not wiretapping because what we're talking about here is explicitly
known to the sender.

2) Not wiretapping because the receivers would see that this was done by a
proxy user agent, in the same way that a standard proxy today identifies
itself in the middle (note, however, that transparent proxies today are
considered wiretaps by this definition!  so by removing transparent
proxies, we're removing a common class of wiretap!)

3) Not wiretapping because the sender can be told of the exact consequence
and also be able to configure out of it.

4) Not applicable - we aren't proposing this at all.

Any disagreement?

Mike

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 3 Apr 2012 08:41:54 +0200 (CEST)

On Tue, 3 Apr 2012, Amos Jeffries wrote:

> On top of that WPAD is still a non-standard mess not supported by 
> non-browser agents

The reason "non-browser agents" don't support it - I claim - is that there's 
just no significant number of users who need it.

I'm the main author of curl, during its 14 years of existance not a single 
user has asked for WPAD support... PAC however, people has asked for, but 
that's a javascript mess not easily supported by a mere "non-browser agent".

I would claim we in the HTTP world haven't found the optimal solution for this 
yet. Unfortunately.

-- 

  / daniel.haxx.se

---

From: Roberto Peon <[email-masked]>
Date: Tue, 3 Apr 2012 00:17:02 -0700

> integrity assertion of the resources match the host in the uris.

Yup, that was also what I was saying before. That would also allow the
first request to tell the UA what the site's policy for subsequent (i.e.
allow MITM or not) would or could be.

I'm agreed on the rest a well..
-=R

---

From: J Ross Nicoll <[email-masked]>
Date: Tue, 03 Apr 2012 09:10:48 +0100

On 03/04/2012 02:55, Adrien W. de Croy wrote:
> In relation to RFC2804, it's one thing to take a position of not 
> taking a position, which is fine and completely reasonable.
>
> wishes of governments, and therefore creates problems for 
> implementors, potentially criminalises users and implementors.  Thats 
> doesn't equate to not taking a position.

On a related note, has everyone seen the UK government is considering 
laws requiring acccess to monitor Internet communication? "The 
government will be able to monitor the calls, emails, texts and website 
visits of everyone in the UK under new legislation set to be announced 
soon." - http://www.bbc.co.uk/news/uk-politics-17576745

Ross

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 03 Apr 2012 10:30:29 +0100

On 04/03/2012 07:32 AM, Mike Belshe wrote:
>> http://tools.ietf.org/html/**rfc2804<http://tools.ietf.org/html/rfc2804>
>
>

Probably. That'll depend on what goes in an I-D I guess.

But yes, while 2804 is relevant for the Daily Telegraph link above,
I would hope its not relevant for HTTP/2.0.

S.

---

From: Henry Story <[email-masked]>
Date: Tue, 3 Apr 2012 11:57:11 +0200

> they do it with their smartphones and it's their problem.

I have recently been thinking about this and I believe that this can be made to 
work in a way that would probably be a lot more flexible that what people think 
is possible here. By using linked data [1] one could effectively get something like
this to function quite well. You can imagine governments publishing a resource
linking to 
  - a resource linking to all the national banks domains and identifier and 
    foreign similar lists
  - a resource linking to company directories (i.e. the NASDAQ, London 
      Stock Exchange, and so on ) which themselves list all the companies and link 
      to them
  - local non public markets companies and foreign equivalents
  - lists of universities and public institutions
  - lists of charities and others
  
This would then create a linked data global web of information about companies and
resources to which one could add local unofficial preferences which could be used
for different players to set their access policies.

Anyway, if you keep in mind the possibility for this type of thing then you can
see that it is not a problem very much at the TLS layer, but at a different layer.

I'll post something soon that goes into more detail on the architecture of this
kind of system.

	Henry

[1] http://linkeddata.org/

> Willy

Social Web Architect
http://bblfish.net/

---

From: Eric Lawrence <[email-masked]>
Date: Tue, 3 Apr 2012 17:07:02 +0000

I believe the last number I heard for WPAD was 3% of users rely upon it.

-----Original Message-----
From: Daniel Stenberg [mailto:[email-masked]] 
Sent: Monday, April 02, 2012 11:42 PM
To: Amos Jeffries
Cc: HTTP Working Group
Subject: proxy config (was Re: multiplexing -- don't do it)

> On top of that WPAD is still a non-standard mess not supported by 

The reason "non-browser agents" don't support it - I claim - is that there's just no significant number of users who need it.

I'm the main author of curl, during its 14 years of existance not a single user has asked for WPAD support... PAC however, people has asked for, but that's a javascript mess not easily supported by a mere "non-browser agent".

I would claim we in the HTTP world haven't found the optimal solution for this yet. Unfortunately.

-- 

  / daniel.haxx.se

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 3 Apr 2012 15:23:54 -0700

On Mar 31, 2012, at 4:11 AM, Mike Belshe wrote:
> On Sat, Mar 31, 2012 at 8:57 AM, Julian Reschke <[email-masked]> wrote:
> On 2012-03-31 01:53, Mike Belshe wrote:
> ...
> 
> Before thinking this way we should look at how well other mandatory but
> optional to use features have turned out.
> 
> One such example is pipelining.  Mandatory for a decade, but optional to
> implement. We still can't turn it on.
> ...
> 
> But then many people have it turned on, and it seems to be on by default in Safari mobile. Maybe the situation is much better than you think.
> 
> The data is overwhelming that it doesn't work.

It works just fine.  The data shows only that a general-purpose browser,
that doesn't even bother to report the nature of network protocol errors,
encounters a small percentage of network problems that exceed its users'
tolerance for failure conditions because its users have no control over
their network.  That might indicate that the browser cannot deploy it, or
it might indicate that there was a protocol bug on the browser that failed
on edge cases (just like Netscape 1-3 had a buffer reading bug that would
only trigger if the blank line CRLF occurred on a 256 byte buffer boundary).

It doesn't indicate anything about whether the feature works in HTTP for
clients that are not browsers or for networks where the administrators
do control their own deployment of intermediaries.

> Data points:
> a) chrome study showing connectivity results on port 80, 443, and 61xxx for websockets showed >10% failures on port 80 for non HTTP protocols.

Unrelated to pipelining.

> b) no major browser has deployed pipelining.  It's not like we don't want to.  We all want to!  Ask Patrick McManus for details - to think this works is just wishful thinking. If all we had to do was turn on pipelining 3 years ago, we would have done it.

Major browsers care about all networks and all customers. Most of the clients
on the Web are not major browsers.  Most of the systems on the Web that use HTTP
pipelining deploy it within environments wherein they do control the network
and can rubbish the stupid intermediaries that fail to implement it correctly.
The rest can and do tolerate 5% failure rates because they actually report
errors to the user and then the user fixes their own network problem.

> For the record - nobody wants to avoid using port 80 for new protocols.  I'd love to!  There is no religious reason that we don't - its just that we know, for a fact, that we can't do it without subjecting a non-trivial number of users to hangs, data corruption, and other errors.  You might think its ok for someone else's browser to throw reliability out the window, but nobody at Microsoft, Google, or Mozilla has been willing to do that...
> 
> As for mobile safari - I mentioned this in my talk the other day - its a bit of a conundrum.  Android's browser (not chrome) also turns on pipelining.  But I know that neither Apple nor the Android team have produced data or analyzed the success or failures of pipelining.  Mobile browsing is downright awful (due to bad content, networking errors, and other things).  It could be that mobile networks have fewer interfering proxies, or it could be that these errors are just getting blamed on other mobile network glitches.  I honestly don't know.  I'd love to see data on the matter.

Mobile networks use proxies that are owned by the mobile network.
That is why they can and do implement pipelining.

We have to realize that HTTP is used everywhere.  The problems you
have encountered while writing a general-purpose browser are not the
same problems that I encounter while writing a spider and a content
management system, what Samsung encounters when writing a TV and a
refrigerator, what Willy encounters while writing a proxy, etc.
There is no universal set of features for HTTP.

I have seen dozens of systems over the years deploy products that are
entirely dependent on chunked requests and never see a single problem
with them because they are interacting with an Apache module that uses
the chunked parser that I wrote.  They don't give a rat's ass about your
experience with a general-purpose browser making use of general Internet
access without any control over the intermediaries.  That is not a problem
they share.

They still need a standard for HTTP that includes the features they use.

> Either way - until someone produces data to contradict the current major browser data - we need to stop dreaming that port 80 is viable for anything other than pure HTTP.  The data we have says its not.

You must be thinking of some other thread.  An exchange over port 80 will
either work or it will not -- the trick is to design the protocol so that
it can succeed, or fails in a safe and recognizable way.

> Either produce new data or admit you don't know and trust what the browser developers are telling you.

Hah!  That's a good one.

Regardless, I consider some form of multiplexing to be a requirement for
whatever replaces HTTP/1.1, since there is no better reason to replace
HTTP/1.1 (tokenizing or compression are hardly worth the bother given how
quickly mobile is catching up to PCs).  I'd rather just replace TCP;
I expect that we'll need a protocol that can operate over multiple mux
and non-mux transports, because HTTP/1.1 works right now over many more
transports than just TCP and TLS.  But mux over TCP is a reasonable start.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 03 Apr 2012 22:54:27 +0000

In message <[email-masked]>, "Roy T. Fielding" w
rites:

>whatever replaces HTTP/1.1, [...]

Seconded, but for different reasons.

First of all, I think we'll see more proxies than currently, because
Ipv4/IPv6 and HTTP-1.0/HTTP-2.0 proxies will be deployed.  Proxies
are in a much better shape to exploit mux than clients are.

Second because it is a much better and more general mechanism than
pipe-lining, while having the exact same properties with respect
to queuing etc.  (I'm prefectly happy with the default level of
mux available is one, until the destination indicates otherwise
by some means in the protocol.)

Third, because mux is the only trick in the book I can see which
will allow us to transfer both TLS and non-TLS in the same TCP
connection.  This is important both for proxies and for sesions
being upgraded from plain to TLS.

Finally because it gives us a growing room we need for the wacko
ideas of the next twenty years.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Wed, 4 Apr 2012 01:46:29 +0200

On Wed, Apr 4, 2012 at 12:23 AM, Roy T. Fielding <[email-masked]> wrote:

> On Sat, Mar 31, 2012 at 8:57 AM, Julian Reschke <[email-masked]>wrote:
>
>> But then many people have it turned on, and it seems to be on by default
>> in Safari mobile. Maybe the situation is much better than you think.
>>
>

I'm starting to get data back, but not in a state that I'd reliably
release. That said, there are very clear indicators of intermediaries
causing problems, especially when the pipeline depth exceeds 3 requests.

> do control their own deployment of intermediaries.

Why would the case be different for HTTP clients that are not browsers? Are
you implying that browsers are more broken in terms of pipelining support
than other HTTP clients? Or simply that they communicate over different
networks?

As for networks that control their own deployments of intermediaries, are
these entirely private networks? If you go over the public internet at any
point, I'd expect to encounter some form of intermediary not controlled by
administrators.

> Data points:
> a) chrome study showing connectivity results on port 80, 443, and 61xxx
> for websockets showed >10% failures on port 80 for non HTTP protocols.
>
>
> Unrelated to pipelining.
>
> b) no major browser has deployed pipelining.  It's not like we don't want
> to.  We all want to!  Ask Patrick McManus for details - to think this works
> is just wishful thinking. If all we had to do was turn on pipelining 3
> years ago, we would have done it.
>
>

That's a fair point, but major browsers are probably in general more
important, due to the vast number of users. Is that widely disagreed? Sorry
if I'm blinded by my personal bias since I work on a browser. I hope this
naive claim won't come off too arrogant.

> and can rubbish the stupid intermediaries that fail to implement it

What are these environments? Are they private networks? In these cases, is
HTTP pipelining that big a win? Do these networks operate on a global
scale? Or are they more local? If local, I'd expect the RTTs to be much
lower, and pipelining to be less of a win.

Also, I'm going to take the opportunity to ask a dumb question (sorry, I
lack your guys' experience with all the uses of HTTP). To what extent do
these other environments matter? If you don't run over the public internet,
instead running over private networks, can't you run whatever protocol you
want anyway? Is it more about saving time and not having to write more
code? Can they just use HTTP/1.1 and forget HTTP/2.0?

> that...
> As for mobile safari - I mentioned this in my talk the other day - its a
> bit of a conundrum.  Android's browser (not chrome) also turns on
> pipelining.  But I know that neither Apple nor the Android team have
> produced data or analyzed the success or failures of pipelining.  Mobile
> browsing is downright awful (due to bad content, networking errors, and
> other things).  It could be that mobile networks have fewer interfering
> proxies, or it could be that these errors are just getting blamed on other
> mobile network glitches.  I honestly don't know.  I'd love to see data on
> the matter.
>
>

It's not clear to me which intermediaries are causing the problems. Your
statement here seems to be predicated on the problematic intermediaries
being located closer to the client. Do we have any data to support this?

> They still need a standard for HTTP that includes the features they use.

What features do they need beyond what's offered in HTTP/1.1? Or is the
assumption that we want to completely kill off HTTP/1.1? What about Mike's
point in his httpbis presentation that we may want different protocols for
the "backoffice" and the general internet?

>
> Either way - until someone produces data to contradict the current major
> browser data - we need to stop dreaming that port 80 is viable for anything
> other than pure HTTP.  The data we have says its not.
>
>

And falls back to HTTP/1.1 in a reasonably fast manner that does not
significantly degrade user experience.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 04 Apr 2012 00:03:01 +0000

The original argument was one about whether it's worth-while specifying 
features that are mandatory to implement, but optional to use.
  
This pipelining thing was given as an example.
  
Personally whilst I think pipelining is more likely to have been fixed 
had it been mandatory to use, maybe it would have been less likely to 
have been included in the spec at all, since in some cases it's quite 
problematic and onerous.
  
So I think we need to get back to the original point is all... 
currently we're extrapolating from 1 data point :)
  
Actually I don't even have a strong feeling that it's worth trying to 
come up with a rule for whether optional to use things are bad or not.  
It needs to be case by case. I'm sure for every example of where o-t-u 
was bad, others can be found where it was good.
  
Adrien

------ Original Message ------
From: "William Chan (陈智昌)" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: "Mike Belshe" <[email-masked]>;"[email-masked] Group" 
<[email-masked]>
Sent: 4/04/2012 11:46:29 a.m.
Subject: Re: multiplexing -- don't do it
 >  But then many people have it turned on, and it seems to be on by 
 >  default in Safari mobile. Maybe the situation is much better than 
 >  you think.
>  
  
  It works just fine.  The data shows only that a general-purpose 
  browser,
  that doesn't even bother to report the nature of network protocol 
  errors,
  encounters a small percentage of network problems that exceed its 
  users'
  tolerance for failure conditions because its users have no control 
  over
  their network.  That might indicate that the browser cannot deploy 
  it, or
  it might indicate that there was a protocol bug on the browser that 
  failed
  on edge cases (just like Netscape 1-3 had a buffer reading bug that 
  would
  only trigger if the blank line CRLF occurred on a 256 byte buffer 
  boundary).
 
 I'm starting to get data back, but not in a state that I'd reliably 
 release. That said, there are very clear indicators of intermediaries 
 causing problems, especially when the pipeline depth exceeds 3 
 requests.

  It doesn't indicate anything about whether the feature works in HTTP 
  for
  clients that are not browsers or for networks where the administrators
  do control their own deployment of intermediaries.
 
 Why would the case be different for HTTP clients that are not 
 browsers? Are you implying that browsers are more broken in terms of 
 pipelining support than other HTTP clients? Or simply that they 
 communicate over different networks?
 
 As for networks that control their own deployments of intermediaries, 
 are these entirely private networks? If you go over the public 
 internet at any point, I'd expect to encounter some form of 
 intermediary not controlled by administrators.

  >Data points:
  >a) chrome study showing connectivity results on port 80, 443, and 
  >61xxx for websockets showed >10% failures on port 80 for non HTTP 
  >protocols.
 >
 >Unrelated to pipelining.
 >
 >>b) no major browser has deployed pipelining.  It's not like we don't 
 >>want to.  We all want to!  Ask Patrick McManus for details - to 
 >>think this works is just wishful thinking. If all we had to do was 
 >>turn on pipelining 3 years ago, we would have done it.
>>
>important, due to the vast number of users. Is that widely disagreed? 
>Sorry if I'm blinded by my personal bias since I work on a browser. I 
>hope this naive claim won't come off too arrogant.
> 
 
 What are these environments? Are they private networks? In these 
 cases, is HTTP pipelining that big a win? Do these networks operate on 
 a global scale? Or are they more local? If local, I'd expect the RTTs 
 to be much lower, and pipelining to be less of a win.
 
 Also, I'm going to take the opportunity to ask a dumb question (sorry, 
 I lack your guys' experience with all the uses of HTTP). To what 
 extent do these other environments matter? If you don't run over the 
 public internet, instead running over private networks, can't you run 
 whatever protocol you want anyway? Is it more about saving time and 
 not having to write more code? Can they just use HTTP/1.1 and forget 
 HTTP/2.0?
 
  The rest can and do tolerate 5% failure rates because they actually 
  report
  errors to the user and then the user fixes their own network problem.
  
  >protocols.  I'd love to!  There is no religious reason that we don't 
  >- its just that we know, for a fact, that we can't do it without 
  >subjecting a non-trivial number of users to hangs, data corruption, 
  >and other errors.  You might think its ok for someone else's browser 
  >to throw reliability out the window, but nobody at Microsoft, 
  >Google, or Mozilla has been willing to do that...
  >
  >As for mobile safari - I mentioned this in my talk the other day - 
  >its a bit of a conundrum.  Android's browser (not chrome) also turns 
  >on pipelining.  But I know that neither Apple nor the Android team 
  >have produced data or analyzed the success or failures of 
  >pipelining.  Mobile browsing is downright awful (due to bad content, 
  >networking errors, and other things).  It could be that mobile 
  >networks have fewer interfering proxies, or it could be that these 
  >errors are just getting blamed on other mobile network glitches.  I 
  >honestly don't know.  I'd love to see data on the matter.
 >
>It's not clear to me which intermediaries are causing the problems. 
>Your statement here seems to be predicated on the problematic 
>intermediaries being located closer to the client. Do we have any data 
>to support this?
> 
> 
 
 What features do they need beyond what's offered in HTTP/1.1? Or is 
 the assumption that we want to completely kill off HTTP/1.1? What 
 about Mike's point in his httpbis presentation that we may want 
 different protocols for the "backoffice" and the general internet?

  >Either way - until someone produces data to contradict the current 
  >major browser data - we need to stop dreaming that port 80 is viable 
  >for anything other than pure HTTP.  The data we have says its not.
 >

---

From: Mike Belshe <[email-masked]>
Date: Tue, 3 Apr 2012 17:19:22 -0700

> do control their own deployment of intermediaries.

If you've got data that shows differently, I'm happy to view it.  But, to
dismiss the only data we have measured right now doesn't seem prudent?

I would very much like to have data from multiple vendors on this issue,
however.

> for websockets showed >10% failures on port 80 for non HTTP protocols.

Very related to the deployability of new protocols over port 80.

> errors to the user and then the user fixes their own network problem.

I thought a requirement of HTTP/2.0 is that we could deploy it on major
browsers on the Internet - is that not a requirement?

> That is why they can and do implement pipelining.

You're speculating, right?  How do you know that mobile networks don't have
pipelining problems?  Have you measured?

> There is no universal set of features for HTTP.

Dedicated networks may have different properties.  But anyone using HTTP
over the general internet will likely run into similar problems that
browsers do.  I thought we wanted this to work over the Internet?

> developers are telling you.

I'm really asking for help here; I'd love to see more data.

> transports than just TCP and TLS.  But mux over TCP is a reasonable start.

I'm sure you know this, but RFC2616 does not run over arbitrary transports.
 Different transports have different features, and that means HTTP maps
onto them differently.  TCP offers a single, bidirectional stream.  SCTP
offers multiple, unidirectional streams.  In order to define how RFC2616
maps onto SCTP, a separate definition was needed:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.   It's not a
complicated definition, but its not the only way to map HTTP onto SCTP.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Apr 2012 07:49:03 +0200

Hi William,

> causing problems, especially when the pipeline depth exceeds 3 requests.

Personally I'm still thinking that if we only pipeline on http/2 and not
on http/1, we'll avoid all the associated risks. The real issue I can
imagine with broken intermediaries is related to those still parsing
requests in *packets* without reassembling them as a stream. Once your
requests exceeds 1 packet (or the product's limit), you can run into
trouble. Seen that on Alteon years ago (was an excellent L3/L4 LB but
marketing made it L7 and caused issues everywhere).

As we suggested in our draft, once the requests are reduced, it's possible
to send the next ones along with the first request in a header field, this
protects us against 1.1-only intermediaries which can't see them.

> point, I'd expect to encounter some form of intermediary not controlled by

We still need to keep in mind that broken intermediaries are deployed at two
places :
  - inside the users' ISP network (eg: caches, LB, compressors)
  - on the server side

When users complain they can't access site X or Y, either they complain on
the ISP side and the ISP has to find a quick fix (last time I experienced
this was just two weeks ago). And when it's on the server side, the fix has
to be applied too otherwise the site loses a lot of visitors (experienced
this at the same time, the fight was whether it was the ISP or the site
which was broken ; the breakage was unrelated to HTTP, it was TCP which
failed due to use of CGN).

What must absolutely be avoided is the random hang that cannot be diagnosed
and the issues which cause random delays. We need a clean fallback to a
working behaviour.

> lower, and pipelining to be less of a win.

It depends. Some corporate users are forced to browse on their laptop via
their corporate VPN and proxies. When you run a VPN on top of 3G in which
you use a proxy, you're exactly like a smartphone user (except you don't
suffer from the DNS round trip).

> code? Can they just use HTTP/1.1 and forget HTTP/2.0?

In my opinion we must not fragment 1.1 and 2.0. If 2.0 cannot replace 1.1
everywhere I will consider it a total failure. It's not acceptable to
design a new protocol that some people will say "I won't use it because X
or Y". I prefer by large "I'm not compatible right now but am planning to
upgrade".

> being located closer to the client. Do we have any data to support this?

I don't have data either but from what I have *observed*, server-side tends
to be a lot more careful at what they deploy so that all their infrastructure
is compatible with their own needs. ISPs tend to deploy something which seems
OK for most usages (and it's not easy for them to catch all corner cases). So
this practice tends to put more breakage at the ISP's than at the content
provider's. Also, when an ISP deploys a transparent cache, economics are much
more involved than when a content provider deploys a load balancer, so the
ability to accept tradeoffs is easy to understand in the former case.

> the "backoffice" and the general internet?

I do think that what's in the backoffice must converge to 2.0 too and that
what's outside may be a superset of this. Once again, personal opinion only.
I would hate to say users "hey we released 2.0 and only browsers will be
able to use it - if you have a web server that's 2.0 and want to put a LB
in front of it, you must degrade it to 1.1 first". That does not make much
sense in my opinion.

> significantly degrade user experience.

This is extremely important (reason why I do like the Upgrade).

Regards,
Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 04 Apr 2012 07:02:18 +0000

>> causing problems, especially when the pipeline depth exceeds 3 requests.

I always thought that the problem in HTTP/1.x is that you can never
quite be sure if there is an un-warranted entity comming after at GET,
so people simply look to see if anything follows the CRNL CRNL and if
so, considers it an entity, even if it starts "GET /foo..."

If so, that is not a problem with pipelining, that is a problem with the
HTTP/1.X spec.

>on http/1,

Agreed.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Apr 2012 09:36:35 +0200

> so, considers it an entity, even if it starts "GET /foo..."

There is an implicit empty body after a GET (content-length: 0), though
I read somewhere (don't remember if it's here or on haproxy ml) that a
few people are sending bodies with GET requests in server environments.

> If so, that is not a problem with pipelining, that is a problem with the

The real problem with pipelining is that 1) some parsers used to read too
much and were unable to rewind, and 2) requests found in circular buffers
and which wrap or are spanned over multiple buffer chunks are not always
processed correctly. There will always be a few remaining cases where there
are implementation bugs, but implementation must be fixed according to specs,
not the other way around. Specs can only consider the risk of relying on too
many buggy implementations.

Willy

---

From: Mike Belshe <[email-masked]>
Date: Wed, 4 Apr 2012 10:10:05 +0200

> protects us against 1.1-only intermediaries which can't see them.

No - you can't rely on packet boundaries at the TCP layer to solve race
conditions at the app layer.  Example, at the time of the first request,
you may not have a second request to bundle with it, but 2ms later, you
might.  So, you'd end up with packet splitting again. And I haven't even
mentioned that the app layer has no idea how big the packet payload is
anyway....

>  - inside the users' ISP network (eg: caches, LB, compressors)

Or at the user's school or corporation.  Or in load balancing equipment in
some shared data center.  Or.... anywhere.  There are myriads of
configurations possible.

> and the issues which cause random delays. We need a clean fallback to a

You're going through all the same thought processes that browser vendors
went through years ago.  It's great, it really is :-)  But, I don't think
you're going to find a pot of gold at the end of this rainbow.

If you really want to try, the firefox bug database is a treasure trove.
 Just go search for pipelining and check out some of the still-open bugs.

145392 <https://bugzilla.mozilla.org/show_bug.cgi?id=145392>nor--Allnobody
NEW---some images do not load [apache CGI pipelining
problem]<https://bugzilla.mozilla.org/show_bug.cgi?id=145392>
465814 <https://bugzilla.mozilla.org/show_bug.cgi?id=465814>maj--Macnobody
UNCO---Not all images load on a page with pipelining
enabled<https://bugzilla.mozilla.org/show_bug.cgi?id=465814>
716840 <https://bugzilla.mozilla.org/show_bug.cgi?id=716840>nor--Windnobody
UNCO---Images get the wrong content with pipelining
enabled<https://bugzilla.mozilla.org/show_bug.cgi?id=716840>

Some of the comments in here confirm my earlier speculation that mobile
browsers using pipelining have simply been letting errors go unchecked.

To quote, "

André Roaldseth 2012-01-10 01:58:28 PST

One of the earliest posts about this problem is
http://forums.mozillazine.org/viewtopic.php?f=38&t=284489 which dates
from 2004.

I have enabled network.http.pipelining and not touched any of the
other pipelining settings.

We became aware of the issue
(http://tech.vg.no/2011/12/14/safari-on-ios-5-randomly-switches-images/)
first with iOS 5 which has pipelining enabled by default. Now we've
reproduced it with Firefox 9 and we have some unconfirmed reports
about it happening with Opera. Several other news pages(like
www.db.no, www.ap.no) has also experienced the problem.

We have lots of tcpdumps from debugging the problem on iOS 5, but
everything looks to be correct in them."

Searching for iOS5 pipelining errors yields lots of other hits from google
on the subject.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 4 Apr 2012 11:06:50 +0200

Hi Mike,

> mentioned that the app layer has no idea how big the packet payload is

It seems we're talking about different things. I'm not saying that we can
shrink the requests to make them fit into TCP segments, I know this is pure
crap and must never be done. I'm saying that we can use HTTP headers to send
some requests once we manage to shrink a request size so that they do not
represent a significant overhead for the fallback case.

Let me be clear on one point : I don't want to rely on any form of HTTP/1.1
pipelining as we know it breaks from time to time. I just want to use plain
non-pipelined HTTP/1.1 to ensure maximum reliability. For instance :

    GET /index.html HTTP/1.1
    Upgrade: HTTP/2.0
    Http2-Req: "/css/style.css", "/js/menu.js", "/favicon.ico", "/img/top.png"
    Connection: Upgrade, Http2-Req

This does not involve 1.1-based pipelining and cleanly falls back to 1.1
when some non-2.0 compatible gateways are in the middle.

I'm clearly aware of a number of issues which come with existing deployments,
some more or less serious, and as much as possible I want the future design
not to rely on too many assumptions.

Regards,
Willy

---

From: Patrick McManus <[email-masked]>
Date: Wed, 04 Apr 2012 09:07:43 -0400

> quite be sure if there is an un-warranted entity comming after at GET,

its not uncommon to have the consumer RST the whole TCP session when
asked to recv too far beyond the current request it is processing. For
some devices "too far" appears to be defined as "any new packet". I
presume some variation of this is where Will's data point comes from.
(Often 3 uncompressed requests fit in 1 packet). 

That class of bug sounds absurd, but its really a pretty common pattern.
As an example: hosts that fail TLS False Start (for which I understand
second hand that Chrome needs to keep a black-list), react badly because
there is TCP data queued when they are in a state that the expect their
peer to be quiet. Same pattern.

The lesson to me is that you want to define a tight set of functionality
that is reasonably testable up front - and that's what you can depend
widely on later. Using anything beyond that demands excessive levels of
pain, complexity, and cleverness.

(and all this pipelining talk as if it were equivalent to spdy mux is
kind of silly. Pipelining's intrinsic HOL problems are at least as bad
of an issue as the interop bugs.)

-Patrick

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 4 Apr 2012 16:58:16 -0400

As long as SPDY is sent over TCP, it also suffers from HOL problems, just
not as bad as pipelining.

I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should framed in
such a way that if running over a protocol like SCTP, that solves the HOL
problems, we should be able to take advantage of it. Due to gzip
compression of headers, even if the transport allowed me to grab messages
out of order, I'd still have to wait for all packets prior in order to
decode the HTTP headers.

Peter

---

From: Peter Lepeska <[email-masked]>
Date: Wed, 4 Apr 2012 17:09:57 -0400

Might as well list all my complaints about SPDY in one spot:

   1. Inter-object dependency due to using a history based compression
   scheme where you need to receive every object in order it was sent to
   decode the last header. This guarantees HOL blocking even if the transport
   supports out of order messages.
   2. SPDY needs to allow headers to be readable by intermediaries. I don't
   mind the mostly binary approach proposed in Willy's document as parsers can
   be developed for wireshark and similar tools.
   3. HTTPS required -- to me that's a showstopper. Have to do this in two
   steps: deploy muxing, which removes the main performance penalty of HTTPS,
   and then go for security.

Other than those, I think it's great.

Peter

On Wed, Apr 4, 2012 at 4:58 PM, Peter Lepeska <[email-masked]> wrote:

> I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should framed
> in such a way that if running over a protocol like SCTP, that solves the
> HOL problems, we should be able to take advantage of it. Due to gzip

---

From: Mike Belshe <[email-masked]>
Date: Wed, 4 Apr 2012 15:05:43 -0700

> out of order, I'd still have to wait for all packets prior in order to

I think people have confusion about layering on top of transport protocols.
 Any time you have an app protocol that wants to take advantage of new
transport features you *MUST* change the definition of how the app protocol
is bound to the lower level transport.  This absolutely applies to HTTP and
TCP/SCTP (not talking about SPDY yet).  For example, RFC2616 does *not*
specify how to use HTTP over SCTP, and a whole I-D exists for that:
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01  This I-D
defines one possible binding between HTTP and SCTP, but others could exist
too.

Why is this necessary?  Well, TCP has a single, bidirectional stream.  SCTP
doesn't have bi-directional streams at all, and instead only has multiple,
uni-directional streams.  So, if you want to leverage the new feature
(streams) you need to define how you're going to bind onto it.  It's
trivial, but doable.

If we had SCTP, we wouldn't do MUX and SPDY.  It's redundant.  That's not
to say that HTTP/2.0 is worse with multiplexing, its just to say that we
wouldn't need to consider it if the transport already had it.  But SCTP is
not viable today or even within the next decade.

Google sponsored a project at the Univ of Delaware where they investigated
SPDY over SCTP already.  A couple of bindings for SPDY over SCTP were
considered:  use stream 0 for a control stream, and send the headers over
that stream.  This has the nice property that it binds the stateful
compression to a single, in-order stream.  Also, as you can imagine, it
introduces a small amount of HoL there.  Another solution was to use N SCTP
streams, with M mux'd SPDY streams on top of it.  Other such bindings could
be considered.  Overall, SCTP was too immature to really benchmark.  The
FreeBSD and Linux implementations of SCTP have many problems already.  The
UoD guys might want to comment, I found the whole thing non-conclusive.

My recommendation:
Designing HTTP/2.0 for SCTP is a mistake and should NOT be a requirement.
 SCTP is not a viable transport over the Internet today, and will not be in
the foreseeable future.  When it is available, an appropriate binding for
HTTP/2.0 can be determined, trivially, and we can worry about it then.
 This is the same approach that was taken for HTTP with
http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Wed, 4 Apr 2012 15:17:23 -0700

On Wed, Apr 4, 2012 at 2:09 PM, Peter Lepeska <[email-masked]> wrote:

> What benefit are you getting by removing it which justifies a slower
mobile experience for users?  All of the proposals for HTTP/2.0 used
stateful, order dependent compressors.

>
>    1. SPDY needs to allow headers to be readable by intermediaries. I
>    don't mind the mostly binary approach proposed in Willy's document as
>    parsers can be developed for wireshark and similar tools.
>
> SPDY does not prevent intermediaries from reading headers, but I don't
know why you think this is a requirement.  I think you're making proxy
scalability more important than user latency, and that is not the tradeoff
I would make.  Speed effects all users, proxies effect a small fraction of
users.   The argument for proxy scalability is also weak and unproven -
compression and decompression is trivial, and not even on the radar for the
google servers as a problem.  The CPU savings of the 6x reduction in number
of connections completely eclipses the tiny CPU use of the compressor.

>
>    1. HTTPS required -- to me that's a showstopper. Have to do this in
>    two steps: deploy muxing, which removes the main performance penalty of
>    HTTPS, and then go for security.
>
>
SPDY doesn't require HTTP as specified.  So you should be happy with its
current form.  However, I think it should require HTTPS, as there is
tangible user benefit to securing the web today.   But I've ranted on this
topic enough elsewhere :-)

Mike

> On Wed, Apr 4, 2012 at 4:58 PM, Peter Lepeska <[email-masked]>wrote:
>

---

From: Peter L <[email-masked]>
Date: Thu, 5 Apr 2012 03:48:33 -0400

Thanks for the explanation on SCTP -- I have only a high level understanding and based on what you said I can't even claim that. 

In general, the in-flight HOL blocking problem is really serious for long fat networks: some mobile, intercontinental, satellite to name a few. So I'd like for HTTP 2.0 to at least hold the promise that it will be addressed. For instance, I proposed two SPDY streams, one high and one low priority. This would at least prevent low pri drops from blocking high pri objects. Do you have other better ideas?

Peter

On Apr 4, 2012, at 6:05 PM, Mike Belshe <[email-masked]> wrote:

> As long as SPDY is sent over TCP, it also suffers from HOL problems, just not as bad as pipelining.
> 
> I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should framed in such a way that if running over a protocol like SCTP, that solves the HOL problems, we should be able to take advantage of it. Due to gzip compression of headers, even if the transport allowed me to grab messages out of order, I'd still have to wait for all packets prior in order to decode the HTTP headers.
> 
> 
> I think people have confusion about layering on top of transport protocols.  Any time you have an app protocol that wants to take advantage of new transport features you *MUST* change the definition of how the app protocol is bound to the lower level transport.  This absolutely applies to HTTP and TCP/SCTP (not talking about SPDY yet).  For example, RFC2616 does *not* specify how to use HTTP over SCTP, and a whole I-D exists for that:  http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01  This I-D defines one possible binding between HTTP and SCTP, but others could exist too.
> 
> Why is this necessary?  Well, TCP has a single, bidirectional stream.  SCTP doesn't have bi-directional streams at all, and instead only has multiple, uni-directional streams.  So, if you want to leverage the new feature (streams) you need to define how you're going to bind onto it.  It's trivial, but doable.
> 
> If we had SCTP, we wouldn't do MUX and SPDY.  It's redundant.  That's not to say that HTTP/2.0 is worse with multiplexing, its just to say that we wouldn't need to consider it if the transport already had it.  But SCTP is not viable today or even within the next decade.
> 
> Google sponsored a project at the Univ of Delaware where they investigated SPDY over SCTP already.  A couple of bindings for SPDY over SCTP were considered:  use stream 0 for a control stream, and send the headers over that stream.  This has the nice property that it binds the stateful compression to a single, in-order stream.  Also, as you can imagine, it introduces a small amount of HoL there.  Another solution was to use N SCTP streams, with M mux'd SPDY streams on top of it.  Other such bindings could be considered.  Overall, SCTP was too immature to really benchmark.  The FreeBSD and Linux implementations of SCTP have many problems already.  The UoD guys might want to comment, I found the whole thing non-conclusive.
> 
> My recommendation:
> Designing HTTP/2.0 for SCTP is a mistake and should NOT be a requirement.  SCTP is not a viable transport over the Internet today, and will not be in the foreseeable future.  When it is available, an appropriate binding for HTTP/2.0 can be determined, trivially, and we can worry about it then.  This is the same approach that was taken for HTTP with http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.
> 
> Mike
> 
> 
>  
> 
> Peter
> 
> 
> On Wed, Apr 4, 2012 at 9:07 AM, Patrick McManus <[email-masked]> wrote:

---

From: Peter L <[email-masked]>
Date: Thu, 5 Apr 2012 04:07:55 -0400

Full disclosure: I work on a web accelerator for satellite that is a network intermediary that dynamically prefetches the objects a page will need prior to the browser requesting them. With this technology, satellite page load times go from 20+ seconds to 6 on average so it's the difference between usable and unusable. If the web goes primarily HTTPS or in general becomes opaque to intermediaries, we'll have to come up with a MITM scheme (for HTTPS) acceptable to our users or invent other ways to achieve prefetching.

On Apr 4, 2012, at 6:17 PM, Mike Belshe <[email-masked]> wrote:

> Inter-object dependency due to using a history based compression scheme where you need to receive every object in order it was sent to decode the last header. This guarantees HOL blocking even if the transport supports out of order messages.
> What benefit are you getting by removing it which justifies a slower mobile experience for users?  All of the proposals for HTTP/2.0 used stateful, order dependent compressors.

In the downstream direction, there is little that is dynamic in HTTP response headers so a simple binary scheme would get most of the benefit with the order dependence.

Requests have cookies and Urls, which are relatively big and super friendly to stateful compression.

That said, have you measured the performance benefit of header compression alone? I mean, how much slower is SPDY over mobile networks without header compression?
>  
> SPDY needs to allow headers to be readable by intermediaries. I don't mind the mostly binary approach proposed in Willy's document as parsers can be developed for wireshark and similar tools.
> SPDY does not prevent intermediaries from reading headers, but I don't know why you think this is a requirement.  I think you're making proxy scalability more important than user latency, and that is not the tradeoff I would make.  Speed effects all users, proxies effect a small fraction of users.   The argument for proxy scalability is also weak and unproven - compression and decompression is trivial, and not even on the radar for the google servers as a problem.  The CPU savings of the 6x reduction in number of connections completely eclipses the tiny CPU use of the compressor.

As per above, intermediaries do more than just improving scalability including caching and acceleration.
> 
>  
> HTTPS required -- to me that's a showstopper. Have to do this in two steps: deploy muxing, which removes the main performance penalty of HTTPS, and then go for security.
> 
> SPDY doesn't require HTTP as specified.  So you should be happy with its current form.  However, I think it should require HTTPS, as there is tangible user benefit to securing the web today.   But I've ranted on this topic enough elsewhere :-)
> 
> Mike
> 
> 
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Apr 2012 10:25:42 +0200

On Thu, Apr 5, 2012 at 9:48 AM, Peter L <[email-masked]> wrote:

> Thanks for the explanation on SCTP -- I have only a high level
> understanding and based on what you said I can't even claim that.
>
> In general, the in-flight HOL blocking problem is really serious for long
> fat networks: some mobile, intercontinental, satellite to name a few. So
> I'd like for HTTP 2.0 to at least hold the promise that it will be
> addressed. For instance, I proposed two SPDY streams, one high and one low
> priority. This would at least prevent low pri drops from blocking high pri
> objects. Do you have other better ideas?
>

Can you explain this proposal further? It doesn't make sense to me as
stated (What do you mean by two SPDY streams? Are these actual SPDY streams
from the spec?). If HTTP/2.0 is layered on TCP, then it fundamentally will
have TCP-level HOL blocking. At the TCP level, there's no concept of
different priority objects, so any packet drop will delay other packets
behind it. SPDY did not attempt to address this problem, since there were
already so many problems higher in the stack. The real solution is to fix
the transport (new UDP-based protocol anyone?), but that's beyond the scope
of this work.

> On Wed, Apr 4, 2012 at 1:58 PM, Peter Lepeska <[email-masked]>wrote:
>
> I think people have confusion about layering on top of transport
> protocols.  Any time you have an app protocol that wants to take advantage
> of new transport features you *MUST* change the definition of how the app
> protocol is bound to the lower level transport.  This absolutely applies to
> HTTP and TCP/SCTP (not talking about SPDY yet).  For example, RFC2616 does
> *not* specify how to use HTTP over SCTP, and a whole I-D exists for that:
> Why is this necessary?  Well, TCP has a single, bidirectional stream.
>  SCTP doesn't have bi-directional streams at all, and instead only has
> multiple, uni-directional streams.  So, if you want to leverage the new
> feature (streams) you need to define how you're going to bind onto it.
>  It's trivial, but doable.
>

---

From: Roberto Peon <[email-masked]>
Date: Thu, 5 Apr 2012 01:30:08 -0700

On Thu, Apr 5, 2012 at 1:07 AM, Peter L <[email-masked]> wrote:

> Full disclosure: I work on a web accelerator for satellite that is a
> network intermediary that dynamically prefetches the objects a page will
> need prior to the browser requesting them. With this technology, satellite
> page load times go from 20+ seconds to 6 on average so it's the difference
> between usable and unusable. If the web goes primarily HTTPS or in general
> becomes opaque to intermediaries, we'll have to come up with a MITM scheme
> (for HTTPS) acceptable to our users or invent other ways to achieve
> prefetching.
>

The (very reasonable) goal is reduced and reasonable latency for your
users, correct?

I'd propose that you could install an explicit proxy, which would enable
you to do any and all of those modifications, subject to the policy demands
of the user and/or site.

Additionally, if server push or equivalent was available, the user should
be able to have the page served to them in the connection setup time plus
connection setup plus ssl handshake, plus bytes/bandwidth modulo slow start
(which can also be mitigated with a SPDY-like SETTINGS frame indicating to
the server the last CWND that it used to you).

So... lets make it so that one can utilize a proxy to do whatever
interesting stuff a proxy would like to do to aid the user (but
explicitly), and, lets also attempt to make it so that these aren't
necessary to achieve optimal or close to optimal results! These all seem
doable...

-=R

> On Wed, Apr 4, 2012 at 2:09 PM, Peter Lepeska <[email-masked]>wrote:
>
> In the downstream direction, there is little that is dynamic in HTTP
> response headers so a simple binary scheme would get most of the benefit
> with the order dependence.
>
> That said, have you measured the performance benefit of header compression
> alone? I mean, how much slower is SPDY over mobile networks without header
> compression?
>
>
>
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Apr 2012 10:42:04 +0200

> friendly to stateful compression.

My understanding is most clients, especially mobile, have less upload
bandwidth than download.

> alone? I mean, how much slower is SPDY over mobile networks without header

http://dev.chromium.org/spdy/spdy-whitepaper says "Header compression
resulted in an ~88% reduction in the size of request headers and an ~85%
reduction in the size of response headers. On the lower-bandwidth DSL link,
in which the upload link is only 375 Kbps, request header compression in
particular, led to significant page load time improvements for certain
sites (i.e. those that issued large number of resource requests). We found
a reduction of 45 - 1142 ms in page load time simply due to header
compression."

> including caching and acceleration.

As previously discussed, make them explicit then. Why do they need to be
transparent?

> topic enough elsewhere :-)
+1 on big user benefit. What's the showstopper here even if TLS is
required? The handshake or the lack of transparency to intermediaries (use
explicit intermediaries then)?

---

From: Eliot Lear <[email-masked]>
Date: Thu, 05 Apr 2012 11:25:26 +0200

Adrien,

On 4/4/12 2:03 AM, Adrien W. de Croy wrote:
>  
> The original argument was one about whether it's worth-while
> specifying features that are mandatory to implement, but optional to use.
>  

Good point.  I raised this in the WG session in Paris and I'll say it
again.  We[*] have an opportunity to consider peeling off different
portions of use cases and applying different solutions to them.  That
leads to specific optimizations, which is a good thing, and avoids or
reduces the options game.  The question for me is whether we can find
the right buckets, as it were.  There is one very large bucket, which is
non-browser use.

Going against all of this is the argument that use of new ports is a
non-starter, in part due to firewall administrator concerns.  I tend to
discount this argument – slightly.  That is- if the use has a good
enough draw, firewall administrators would, I think on the whole, come
around.  More-so when the alternative is losing visibility due to
everything being encrypted in payload.

Eliot

[*] Who is this “we”, anyway?  That in itself is worthy of discussion.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 05 Apr 2012 09:45:01 +0000

------ Original Message ------
From: "Eliot Lear" <[email-masked]>
>the right buckets, as it were.  There is one very large bucket, which 
>is non-browser use.
>
>non-starter, in part due to firewall administrator concerns.  I tend 
>to discount this argument – slightly.  That is- if the use has a good 
  
There are a bunch of issues related to either keeping the same port or 
choosing another.
  
One argument is that getting a new port opened on a firewall can take a 
long time, due to various issues.  One of these issues is ability to 
control.  However, until firewall software is updated, it won't be able 
to control upgraded traffic over port 80 anyway, except for maybe 
breaking the upgrade mechanism.
  
In fact I think there will be a bunch of intermediaries (mainly CPE) 
that will break the upgrade.  I know earlier versions of WinGate didn't 
strip headers matching Connection tokens, so would pass the Upgrade 
through, and the 101 back, but barf on the new protocol.
  
I also suspect there is a plethora of cheap DSL/NAT routers which do 
port 80 inspection which may break.  Whether they break in a way that 
prevents operation or not is another matter.
  
I also don't know of any cheap DSL/NAT that wouldn't just allow port 
(say) 100 out with no trouble.
  
Using another port will also bypass issues with ISP intercepting 
proxies.. until they are upgraded to actually handle the new protocol.
  
One issue would be trying to figure out which port to make a connection 
attempt on.  Could use a IPv6 approach.  Try connecting to both at 
once, and whichever returns a SYN-ACK first you use that one.  Coupled 
with attempts to prefer IPv6 this would result in 4 simultaneous 
connection attempts though, and in fact most sites running servers 
would probably be running on both ports, so you may still need a way to 
favour port (say) 100.
  
In that way, using port 443 with TLS was a smart move, since it allowed 
negotiation below HTTP using NPN, so it became a non-issue.  The only 
similar approach in TCP would be maybe a NPN-like mechanism as a TCP 
option, which I think would be relatively poorly supported in stacks.  
That's what the port number was intended to do.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Apr 2012 12:07:16 +0200

On Thu, Apr 05, 2012 at 09:45:01AM +0000, Adrien W. de Croy wrote:
> control.

Indeed.

> However, until firewall software is updated, it won't be able 

If we apply a correct fallback to 1.1, your product will still be
able to control the traffic as 1.1. This is why I think that it is
very important to be backwards compatible with 1.1 : the upgrade is
the most transparent possible and admins have no reason to explicitly
block it. If we're not compatible, many admins will not make the effort
of opening the new port since it will require equipments they don't
have.

> prevents operation or not is another matter.

Don't forget that WebSocket readily uses this mechanism and that such
bugs are already being reported to vendors. By the time we ship HTTP/2.0
a number of these implementation bugs will have been fixed, and not
everyone will have deployed V2 anyway.

Regards,
Willy

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Thu, 05 Apr 2012 10:59:58 +0000

----
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
WinGate 7 is released! - http://www.wingate.com/getlatest/

------ Original Message ------
From: "Willy Tarreau" <[email-masked]>
>of opening the new port since it will require equipments they don't
  
Existing compliant 1.1 proxies will remove the Upgrade header, since it 
references a protocol that it won't know yet.
  
Unless it already adopts a strategy of getting out of the way (moving 
to tunnel).
  
Do we have any idea about how many will pass it through and therefore 
allow 2.0 to function?
  
Otherwise these things will keep their users in 1.1 land until they are 
upgraded
  
>everyone will have deployed V2 anyway.
  
OK.  Would be interesting to see stats on rates of failure and why - if 
you have any.
  
Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Apr 2012 13:29:46 +0200

> references a protocol that it won't know yet.

Which is intended here.

> Do we have any idea about how many will pass it through and therefore 

I guess that few proxies will let it pass through, resulting in a
satisfying filtering ability for enterprise or school admins. All the
(explicit) proxies I have tested so far successfully remove the headers
referenced in the Connection field. On the server-side, infrastructure
components are more likely to support this (at least those which already
do with websocket).

> Otherwise these things will keep their users in 1.1 land until they are 

That's what I'd really like to see happen : a smooth and transparent
opening of 2.0. Probably that for HTTPS, NPN might result in a faster
adoption since there are less controls, so that will not change anything
for admins : either they already block and will continue to do so, or
they already don't care and wont either.

> OK.  Would be interesting to see stats on rates of failure and why - if 

The only failure I'm aware of at the moment is TrendMicro's OfficeScan
software blocking traffic to port 80.

Regards,
Willy

---

From: Adrien de Croy <[email-masked]>
Date: Thu, 05 Apr 2012 23:50:33 +1200

On 5/04/2012 11:29 p.m., Willy Tarreau wrote:
> adoption since there are less controls, so that will not change 
> anything for admins : either they already block and will continue to 
> do so, or they already don't care and wont either.

I think a lot of the sites that allow 443 through are growing more and 
more uncomfortable with it.  So it's likely to change, esp as traffic 
migrates to https.

Therefore I wouldn't assume things will remain the way they currently 
are - in terms of people allowing or not caring.

I think the "smooth" upgrade path might take aeons :)

It would be interesting if it were possible to do an experiment using 
another port.  Google would be in a position to test that :)

Adrien

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Apr 2012 13:56:11 +0200

On Thu, Apr 5, 2012 at 1:50 PM, Adrien de Croy <[email-masked]> wrote:

>> for admins : either they already block and will continue to do so, or they
>> already don't care and wont either.
>>
>
> Therefore I wouldn't assume things will remain the way they currently are
> - in terms of people allowing or not caring.
>

Do you mean like we did for the WebSocket experiment over port 61985? See
http://www.ietf.org/mail-archive/web/tls/current/msg05593.html.

I'm already having a lot of discussions internally at Google with various
folks about experiments we can run to provide data here. If you have any
suggestions, I'm open to implementing them.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Apr 2012 14:11:33 +0200

Agreed.

> I think the "smooth" upgrade path might take aeons :)

It's not a problem, we mostly want it for mobile users, and in general
those who don't use a proxy and are suffering from the long latency links.

Willy

---

From: Patrick McManus <[email-masked]>
Date: Thu, 05 Apr 2012 09:13:28 -0400

On Thu, 2012-04-05 at 10:25 +0200, William Chan (陈智昌) wrote:

>  stack. The real solution is to fix the transport (new UDP-based
> protocol anyone?), but that's beyond the scope of this work.

Although I agree a udp based proposal is unlikely to bear fruit, I don't
see that it is a priori beyond the scope of the HTTP/2 work. I think our
charter asks for proposals that reduce TCP connection count - that would
certainly qualify :) WebRTC is doing something kind of similar with
sctp/dtls/udp layering, right?

There are a huge amount of unknowns there, which is a terrific argument
for rallying around spdy because it is well experimented with already
and is known to solve some hard problems. But if someone were to invest
in a prototype, a spec, and some test results of a udp system I would
find that a much more interesting thing to consider than another
proposal for some variation of spdy-lite.

My weak understanding of dtls is that it has the potential to save
another rtt over the tcp version :)

-Patrick

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Apr 2012 15:27:15 +0200

> certainly qualify :) WebRTC is doing something kind of similar with

LOL :)

> proposal for some variation of spdy-lite.

It's still vaporware so I'm not going to say much more than "we (Google)
know and we're looking into it." The publicly visible updates can be seen
here: http://code.google.com/p/chromium/issues/detail?id=121577 &&
http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/net/network_stats.h
.

I'd prefer we focus on SPDY over TCP for now, and we can discuss what SPDY
might look like over different transports in the future when we have a
concrete proposal and data, rather than diving into that rathole right now.
I'm personally a big fan of proposing things when you have data to back up
your claims.

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 5 Apr 2012 10:05:39 -0400

The idea is just a partial solution to the HOL blocking problem that at
least decreases the likelihood that HOL issue will block high priority
objects. I don't yet know the SPDY protocol well enough but the idea is
that you would have two SPDY streams running over two TCP connections.
Anything that the browser deems as blocking page load, or for another
reason high priority, will go over one SPDY stream and everything else will
go over the other.

I agree that a UDP-based transport that supports out of order packets would
completely solve HOL blocking for SPDY. My misunderstanding was that SCTP
was such a transport but Mike set me straight. In any case, there are no
obvious candidates for this so I agree we can't really design for it.

Still I think we should support inter-object dependencies only if there's a
real benefit, which I believe there is in the upstream but not so sure in
the downstream, as compared to simply going binary.

Peter

On Thu, Apr 5, 2012 at 4:25 AM, William Chan (陈智昌) <[email-masked]>wrote:

>> Google sponsored a project at the Univ of Delaware where they
>> investigated SPDY over SCTP already.  A couple of bindings for SPDY over
>> SCTP were considered:  use stream 0 for a control stream, and send the
>> headers over that stream.  This has the nice property that it binds the
>> stateful compression to a single, in-order stream.  Also, as you can
>> imagine, it introduces a small amount of HoL there.  Another solution was
>> to use N SCTP streams, with M mux'd SPDY streams on top of it.  Other such
>> bindings could be considered.  Overall, SCTP was too immature to really
>> benchmark.  The FreeBSD and Linux implementations of SCTP have many
>> problems already.  The UoD guys might want to comment, I found the whole
>> thing non-conclusive.
>>
>> My recommendation:

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 5 Apr 2012 10:09:42 -0400

On Thu, Apr 5, 2012 at 4:42 AM, William Chan (陈智昌) <[email-masked]>wrote:

>> That said, have you measured the performance benefit of header
>> compression alone? I mean, how much slower is SPDY over mobile networks
>> without header compression?
>>
>

I wonder what % of this is due to request header compression and what
percent response header. Also, I think much of the 85% reduction in
response headers can be gotten by going binary. Requests not so much.

> As previously discussed, make them explicit then. Why do they need to be

I like the idea of the "trusted" proxy.

>>>> I think SPDY (or whatever the HTTP 2.0 muxing protocol is) should
>>>> framed in such a way that if running over a protocol like SCTP, that solves
>>>> the HOL problems, we should be able to take advantage of it. Due to gzip

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 5 Apr 2012 10:11:05 -0400

I like this vision. No disagreements with any of the below.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 5 Apr 2012 16:20:37 +0200

On Thu, Apr 5, 2012 at 4:05 PM, Peter Lepeska <[email-masked]> wrote:

> that you would have two SPDY streams running over two TCP

I suggest you read up on SPDY a bit more first and come back. It may save a
lot of people time in explaining things :) At the minimum, read up on SPDY
sessions and streams (
http://willchan.github.com/SPDY-Specification/draft-mbelshe-spdy-00.html#rfc.section.2.1
).

connections. Anything that the browser deems as blocking page load, or for
> another reason high priority, will go over one SPDY stream and everything
> else will go over the other.

I think you mean using two SPDY sessions over separate TCP connections.
There's nothing in the SPDY specification which says you can't use multiple
connections, and that's up to the user-agent. That said, there are
downsides to doing so. I think we've already discussed many of the reasons
we want to use fewer connections previously, so I won't belabor those
points. I think the reason you bring up multiple connections is to work
around problems in the transport, which is why I think long-term we should
fix the transport layer too. It may be the case that a better client use of
SPDY would be to open two connections instead of a single one, but I would
push back very strongly against that in Chromium and only do it if we found
it was truly necessary.

> I agree that a UDP-based transport that supports out of order packets
> would completely solve HOL blocking for SPDY. My misunderstanding was that
> SCTP was such a transport but Mike set me straight. In any case, there are
> no obvious candidates for this so I agree we can't really design for it.
>
> Still I think we should support inter-object dependencies only if there's
> a real benefit, which I believe there is in the upstream but not so sure in
>>> In general, the in-flight HOL blocking problem is really serious for
>>> long fat networks: some mobile, intercontinental, satellite to name a few.
>>> So I'd like for HTTP 2.0 to at least hold the promise that it will be
>>> If we had SCTP, we wouldn't do MUX and SPDY.  It's redundant.  That's
>>> not to say that HTTP/2.0 is worse with multiplexing, its just to say that
>>> we wouldn't need to consider it if the transport already had it.  But SCTP
>>> is not viable today or even within the next decade.
>>>
>>> Designing HTTP/2.0 for SCTP is a mistake and should NOT be a
>>> requirement.  SCTP is not a viable transport over the Internet today, and
>>> will not be in the foreseeable future.  When it is available, an
>>> appropriate binding for HTTP/2.0 can be determined, trivially, and we can
>>> worry about it then.  This is the same approach that was taken for HTTP
>>> with http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.
>>>
>>> Mike
>>>
>>>
>>>
>>>
>>>>
>>>> Peter
>>>>
>>>>

---

From: Jon Leighton <[email-masked]>
Date: Thu, 05 Apr 2012 11:17:00 -0400

On 04/04/2012 06:05 PM, Mike Belshe wrote:
>
>
> On Wed, Apr 4, 2012 at 1:58 PM, Peter Lepeska <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     framed in such a way that if running over a protocol like SCTP,
>     that solves the HOL problems, we should be able to take advantage
>     of it. Due to gzip compression of headers, even if the transport
>     allowed me to grab messages out of order, I'd still have to wait
>     for all packets prior in order to decode the HTTP headers.
>
>
>
> protocols.  Any time you have an app protocol that wants to take 
> advantage of new transport features you *MUST* change the definition 
> of how the app protocol is bound to the lower level transport.  This 
> absolutely applies to HTTP and TCP/SCTP (not talking about SPDY yet). 
>  For example, RFC2616 does *not* specify how to use HTTP over SCTP, 
> and a whole I-D exists for that: 
> defines one possible binding between HTTP and SCTP, but others could 
> exist too.
>
> multiple, uni-directional streams.  So, if you want to leverage the 
> new feature (streams) you need to define how you're going to bind onto 
> it.  It's trivial, but doable.
>
> not to say that HTTP/2.0 is worse with multiplexing, its just to say 
> that we wouldn't need to consider it if the transport already had it. 
>  But SCTP is not viable today or even within the next decade.
>
> investigated SPDY over SCTP already.  A couple of bindings for SPDY 
> over SCTP were considered:  use stream 0 for a control stream, and 
> send the headers over that stream.  This has the nice property that it 
> binds the stateful compression to a single, in-order stream.  Also, as 
> you can imagine, it introduces a small amount of HoL there.  Another 
> solution was to use N SCTP streams, with M mux'd SPDY streams on top 
> of it.  Other such bindings could be considered.  Overall, SCTP was 
> too immature to really benchmark.  The FreeBSD and Linux 
> implementations of SCTP have many problems already.  The UoD guys 
> might want to comment, I found the whole thing non-conclusive.

For anyone interested, here's a link to a summary of the work 
http://www.eecis.udel.edu/~leighton/SPDY.html 
<http://www.eecis.udel.edu/%7Eleighton/SPDY.html>. Under the conditions 
tested, SPDY over SCTP was clearly faster than SPDY over TCP. This is 
true regardless of which mapping was used. Though the data is not 
provided in the summary, using SCTP stream 0 as a control stream for 
SPDY headers was only very slightly faster than sending headers on the 
same SCTP stream as the data. There were some issues with the linux 
implementation of SCTP that had to be worked around (most since fixed), 
but I can't comment on any issues with SCTP on FreeBSD as we decided 
against trying to port Chrome and the flip_in_mem_edsm_server to 
FreeBSD. The results were inconclusive with regard to how best to map 
SPDY to SCTP. Regarding the benefit of using SCTP to avoid HOL blocking, 
the results are pretty straightforward - SPDY performed better over SCTP 
than TCP. Increasing the delay and loss increases SCTP's advantage.

> requirement.  SCTP is not a viable transport over the Internet today, 
> and will not be in the foreseeable future.  When it is available, an 
> appropriate binding for HTTP/2.0 can be determined, trivially, and we 
> can worry about it then.  This is the same approach that was taken for 
> HTTP with http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01.
>
> Mike
>
>
>
>     Peter
>
>
>     On Wed, Apr 4, 2012 at 9:07 AM, Patrick McManus
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         > In message <[email-masked]
>         <mailto:[email-masked]>>, Willy Tarreau writes:
>         >

---

From: Roberto Peon <[email-masked]>
Date: Thu, 5 Apr 2012 09:32:37 -0700

So long as we provide an appropriate mapping onto transports that either do
or do not multiplex, I think we can take advantage of any improvements in
transports.
I think that we should be able to assume reliable and in-order guarantees
are provided for any stream of a transport that we'd use, however... the
use of any transport that does not offer those guarantees would add much
complexity for dubious gain.

-=R

---

From: Peter Lepeska <[email-masked]>
Date: Thu, 5 Apr 2012 12:43:56 -0400

What's the main reason for the benefit? If it's just that SCTP is less of a
good citizen in how it handles a lost packet and backs off slower than TCP
then it's not something to get excited about. Have you done much analysis
to explore the reason for SCTP being faster?

Peter

On Thu, Apr 5, 2012 at 11:00 AM, Jon Leighton <[email-masked]> wrote:

> **
> http://www.eecis.udel.edu/~leighton/SPDY.html. Under the conditions
> tested, SPDY over SCTP was clearly faster than SPDY over TCP. This is true
> regardless of which mapping was used. Though the data is not provided in
> the summary, using SCTP stream 0 as a control stream for SPDY headers was
> only very slightly faster than sending headers on the same SCTP stream as
> the data. There were some issues with the linux implementation of SCTP that
> had to be worked around (most since fixed), but I can't comment on any
> issues with SCTP on FreeBSD as we decided against trying to port Chrome and
> the flip_in_mem_edsm_server to FreeBSD. The results were inconclusive with
> regard to how best to map SPDY to SCTP. Regarding the benefit of using SCTP
> to avoid HOL blocking, the results are pretty straightforward - SPDY
> performed better over SCTP than TCP. Increasing the delay and loss
> increases SCTP's advantage.
>
>
>  My recommendation:

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Apr 2012 11:46:28 -0500

It seems like a set of deliverables for us could then be:

1. A format for HTTP messages that shows how to get one into a set of bits, but doesn't show how to get those bits onto a transport protocol
2. A specification of how to get those messages across a reliable, in-order, not-multiplexed transport 
3. Details of #2 on TCP

leaving the specification of #2 on other suitable transports for future / other work, as well as leaving #1 on multiplexed transport for future / other work.

How do people feel about this? In particular, is the separation between #2 and #3 necessary and good? Does anyone want to attempt more in this WG (I'm hearing many people saying "no")?

On 05/04/2012, at 11:32 AM, Roberto Peon wrote:

> So long as we provide an appropriate mapping onto transports that either do or do not multiplex, I think we can take advantage of any improvements in transports.
> I think that we should be able to assume reliable and in-order guarantees are provided for any stream of a transport that we'd use, however... the use of any transport that does not offer those guarantees would add much complexity for dubious gain.
> 
> -=R
> 
> On Thu, Apr 5, 2012 at 3:13 PM, Patrick McManus <[email-masked]> wrote:
> It's still vaporware so I'm not going to say much more than "we (Google) know and we're looking into it." The publicly visible updates can be seen here: http://code.google.com/p/chromium/issues/detail?id=121577 && http://code.google.com/searchframe#OAMlx_jo-ck/src/chrome/browser/net/network_stats.h.
> 
> I'd prefer we focus on SPDY over TCP for now, and we can discuss what SPDY might look like over different transports in the future when we have a concrete proposal and data, rather than diving into that rathole right now. I'm personally a big fan of proposing things when you have data to back up your claims.
> 
> 

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

---

From: Mike Belshe <[email-masked]>
Date: Thu, 5 Apr 2012 09:55:18 -0700

On Thu, Apr 5, 2012 at 9:46 AM, Mark Nottingham <[email-masked]> wrote:

> 1. A format for HTTP messages that shows how to get one into a set of
> bits, but doesn't show how to get those bits onto a transport protocol
> leaving the specification of #2 on other suitable transports for future /
> other work, as well as leaving #1 on multiplexed transport for future /
> other work.
>
> How do people feel about this? In particular, is the separation between #2
> and #3 necessary and good? Does anyone want to attempt more in this WG (I'm
> hearing many people saying "no")?
>

I think you're basically talking about sections 2 & 3 of the SPDY spec?
 I'm okay with that, and I think any reasonable protocol will do this as a
mechanism to ensure reasonable HTTP/1.1 to HTTP/2.0 transition.

In general, I think we should stop talking about unknown transports or
transports which we don't think are targets (and I put SCTP into this
category).  Designing for transports that don't exist is likely to make our
implementations on the transports that do exist (TCP) watered down or
worse.  In other words, the least-common-denominator sucks....  Further,
NOBODY is going to implement HTTP/2.0 on the unknown transport.  So
whatever we do design for these unknown transports will be untested and
purely theoretical.

Mike

> > So long as we provide an appropriate mapping onto transports that either
> do or do not multiplex, I think we can take advantage of any improvements
> in transports.
> > I think that we should be able to assume reliable and in-order
> guarantees are provided for any stream of a transport that we'd use,
> however... the use of any transport that does not offer those guarantees
> would add much complexity for dubious gain.
> >
> > -=R
> >
> > I'd prefer we focus on SPDY over TCP for now, and we can discuss what
> SPDY might look like over different transports in the future when we have a

---

From: Mike Belshe <[email-masked]>
Date: Thu, 5 Apr 2012 10:05:19 -0700

On Thu, Apr 5, 2012 at 9:43 AM, Peter Lepeska <[email-masked]> wrote:

> What's the main reason for the benefit? If it's just that SCTP is less of
> a good citizen in how it handles a lost packet and backs off slower than
> TCP then it's not something to get excited about. Have you done much
> analysis to explore the reason for SCTP being faster?
>

I believe it's due to unrealistic packet loss simulation.  The 1%/2% loss
is inaccurate (and in the wrong place for mobile networks, where this
happens below the transport) and the modeling of packet loss as random is
unrealistic (real internets don't randomly lose packets that much - its
much more correlated due to buffer overruns).  The net result is that SCTP
looks awesome with random loss, because it picks up packets that otherwise
would have been head-of-line blocked.  But, I don't believe this has
anything to do with the real world.

Sorry to condense over a year of SPDY research with packet loss into three
sentences :-)  I need to write all this stuff up.

Mike

>
> Peter
>
>
> On Thu, Apr 5, 2012 at 11:00 AM, Jon Leighton <[email-masked]>wrote:
>
>> **

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Thu, 5 Apr 2012 17:08:44 +0000

I think that's a great start. Multiplexing is indeed a very tricky issue. It has been tried 3 or 4 times in the context of HTTP and always run into tough corner cases. I am not saying that it impossible but I do think it is orthogonal to item #1. As part of #2/3 I think this still leaves the task of finding an efficient framing model that is defined outside the HTTP message itself. 

Henrik

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Thursday, April 05, 2012 9:46 AM
To: Roberto Peon
Cc: William Chan (陈智昌); Willy Tarreau; patrick mcmanus; [email-masked] Group; Roy T. Fielding; Poul-Henning Kamp; Mike Belshe; Peter L
Subject: HTTP -> Messages -> Transport factoring

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

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 5 Apr 2012 13:17:41 -0500

On 05/04/2012, at 11:55 AM, Mike Belshe wrote:

> In general, I think we should stop talking about unknown transports or transports which we don't think are targets (and I put SCTP into this category).  Designing for transports that don't exist is likely to make our implementations on the transports that do exist (TCP) watered down or worse.  In other words, the least-common-denominator sucks....  Further, NOBODY is going to implement HTTP/2.0 on the unknown transport.  So whatever we do design for these unknown transports will be untested and purely theoretical.

Right. I can see accommodating the potential for these things by putting a bit of thought into how our specs are factored, but am *not* suggesting that we require an existence proof, or spend significant time assuring that they're possible. 

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

---

From: Jon Leighton <[email-masked]>
Date: Thu, 05 Apr 2012 14:18:30 -0400

On 04/05/2012 12:43 PM, Peter Lepeska wrote:
> What's the main reason for the benefit? If it's just that SCTP is less 
> of a good citizen in how it handles a lost packet and backs off slower 
> than TCP then it's not something to get excited about. Have you done 
> much analysis to explore the reason for SCTP being faster?

Although there's some variation in the details between the different 
implementations on different OSes, and there are various sysctl knobs 
you can turn, SCTP's congestion control mechanism is essentially the 
same as TCP's. I'm not certain, but I think it was a design goal to 
ensure that SCTP was no more aggressive than TCP. It's not fundamentally 
any more or less a good citizen.

As Mike already mentioned, I think the reason SCTP does better with loss 
is that it avoids a lot of HOL blocking. Getting HOL blocked on a 
response that's going to cause the browser to open a new connection is a 
problem, and there was a lot of opportunity for that problem given that 
most of the test pages opened 10 or more connections and several opened 
more than 30. I don't know how much SCTP benefited from the random loss 
model. Certainly using a more realistic loss model would improve the 
results.

> Peter
>
> On Thu, Apr 5, 2012 at 11:00 AM, Jon Leighton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>>     On Wed, Apr 4, 2012 at 1:58 PM, Peter Lepeska
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         I think SPDY (or whatever the HTTP 2.0 muxing protocol is)
>>         should framed in such a way that if running over a protocol
>>         like SCTP, that solves the HOL problems, we should be able to
>>         take advantage of it. Due to gzip compression of headers,
>>         even if the transport allowed me to grab messages out of
>>         order, I'd still have to wait for all packets prior in order
>>         to decode the HTTP headers.
>>
>>
>>
>>     advantage of new transport features you *MUST* change the
>>     definition of how the app protocol is bound to the lower level
>>     transport.  This absolutely applies to HTTP and TCP/SCTP (not
>>     talking about SPDY yet).  For example, RFC2616 does *not* specify
>>     how to use HTTP over SCTP, and a whole I-D exists for that:
>>     http://tools.ietf.org/html/draft-natarajan-http-over-sctp-01
>>      This I-D defines one possible binding between HTTP and SCTP, but
>>     others could exist too.
>>
>>     Why is this necessary?  Well, TCP has a single, bidirectional
>>     stream.  SCTP doesn't have bi-directional streams at all, and
>>     instead only has multiple, uni-directional streams.  So, if you
>>     want to leverage the new feature (streams) you need to define how
>>     you're going to bind onto it.  It's trivial, but doable.
>>
>>     If we had SCTP, we wouldn't do MUX and SPDY.  It's redundant.
>>      That's not to say that HTTP/2.0 is worse with multiplexing, its
>>     just to say that we wouldn't need to consider it if the transport
>>     already had it.  But SCTP is not viable today or even within the
>>     next decade.
>>
>>     investigated SPDY over SCTP already.  A couple of bindings for
>>     SPDY over SCTP were considered:  use stream 0 for a control
>>     stream, and send the headers over that stream.  This has the nice
>>     property that it binds the stateful compression to a single,
>>     in-order stream.  Also, as you can imagine, it introduces a small
>>     amount of HoL there.  Another solution was to use N SCTP streams,
>>     with M mux'd SPDY streams on top of it.  Other such bindings
>>     could be considered.  Overall, SCTP was too immature to really
>>     benchmark.  The FreeBSD and Linux implementations of SCTP have
>>     many problems already.  The UoD guys might want to comment, I
>>     found the whole thing non-conclusive.
>
>     <http://www.eecis.udel.edu/%7Eleighton/SPDY.html>. Under the
>     conditions tested, SPDY over SCTP was clearly faster than SPDY
>     over TCP. This is true regardless of which mapping was used.
>     Though the data is not provided in the summary, using SCTP stream
>     0 as a control stream for SPDY headers was only very slightly
>     faster than sending headers on the same SCTP stream as the data.
>     There were some issues with the linux implementation of SCTP that
>     had to be worked around (most since fixed), but I can't comment on
>     any issues with SCTP on FreeBSD as we decided against trying to
>     port Chrome and the flip_in_mem_edsm_server to FreeBSD. The
>     results were inconclusive with regard to how best to map SPDY to
>     SCTP. Regarding the benefit of using SCTP to avoid HOL blocking,
>     the results are pretty straightforward - SPDY performed better
>     over SCTP than TCP. Increasing the delay and loss increases SCTP's
>     advantage.
>
>
>>     My recommendation:
>>     requirement.  SCTP is not a viable transport over the Internet
>>     today, and will not be in the foreseeable future.  When it is
>>     available, an appropriate binding for HTTP/2.0 can be determined,
>>     trivially, and we can worry about it then.  This is the same
>>     approach that was taken for HTTP with

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 05 Apr 2012 19:24:47 +0000

On 05/04/2012, at 11:55 AM, Mike Belshe wrote:

>> In other words, the least-common-denominator sucks.... 

You don't have to resort to l-c-d in order to make your protocol
non-hostile to other transports.

In many ways TCP, certainly compared to many other contenders at
the time of distinction, _is_ l-c-d:  Just a byte stream.

I think we can take it as a given that HTTP over UDP will exist pretty
soon:  Between a surrogate like Varnish or HA-Proxy and the http-server
in the same rack, it would cut a fair bit time of transactions and
a lot of objects fit perfectly well inside a 64Kb UDP packet.

>> Mark Nottingham writes:

>Right. I can see accommodating the potential for these things by putting 
>a bit of thought into how our specs are factored, but am *not*
>suggesting that we require an existence proof, or spend significant time
>assuring that they're possible.

seconded.

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Apr 2012 21:27:23 +0200

Hi,

> whatever we do design for these unknown transports will be untested and

+1, let's keep that for later, we just need not to overdesign in order not
to make this harder later.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 5 Apr 2012 21:34:30 +0200

Hi Mark,

On Thu, Apr 05, 2012 at 11:46:28AM -0500, Mark Nottingham wrote:
> and #3 necessary and good?

I was not sure I correctly parsed this question the first time :-)

The separation is useful but not mandatory. Right now HTTP is being used
a lot at least on UNIX stream sockets between processes on a same system,
because UNIX sockets work exactly like TCP sockets except you don't have
IP:port at each end, and they're much cheaper. I'm saying that the separation
is not mandatory because till now, HTTP was spec'd to run on top of TCP and
had no issue being ported to UNIX sockets, so I think that TCP is an appropriate
model for the target eventhough it will probably not be the only one in the
field.

Leaving #2 would be too hard an exercice for the first round in my opinion, but
should be kept in mind for future work.

> Does anyone want to attempt more in this WG (I'm hearing many people saying "no")?

I'd say "no", we already have enough work for a first draft here.

Regards,
Willy

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Apr 2012 21:46:06 +0200

> a lot of objects fit perfectly well inside a 64Kb UDP packet.

I'm old enough to remember when NFS mostly moved from UDP to TCP.
Are they moving back?  Where/why not?

Grüße, Carsten

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 05 Apr 2012 20:42:10 +0000

In message <[email-masked]>, Carsten Bormann writ

>Are they moving back?  Where/why not?

The usage-model for NFS is that generally things are read/write,
cannot fail and you move massive amounts of data around.

The move from UDP to TCP more or less coincided with "massive" growing
from below 64k to above 64k, where you'd have to start doing the
hard work with UDP.

The HTTP/UDP use-case is different, in that we are specifically
talking about non-transactional small object retrival, but the
64k limit is of course the same thing.

Once of the attractions of HTTP/UDP is that you can multicast and
whichever server happens to have that icon will send it to you.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Apr 2012 23:06:09 +0200

> 64k limit is of course the same thing.

How does the intermediary know that the object will be small (< 64 KiB minus epsilon)?
(Maybe there is some configuration that makes this prediction possible.)
What happens if the prediction was wrong?
(http://tools.ietf.org/html/draft-ietf-core-block is one way of handling this case, but maybe not the one you have in mind.)

> whichever server happens to have that icon will send it to you.

If all those servers can handle the load of discarding lots of requests...
(And assuming the set of servers actually responding is small enough not to cause implosion issues.)
Is there anything written up on this server-side "HTTP over UDP" that I can consume before bothering you further?

Grüße, Carsten

---

From: Adrien de Croy <[email-masked]>
Date: Fri, 06 Apr 2012 11:07:26 +1200

apologies all... email client put sig at top instead of bottom.... sigh

On 5/04/2012 10:59 p.m., Adrien W. de Croy wrote:
> Existing compliant 1.1 proxies will remove the Upgrade header, since 
> it references a protocol that it won't know yet.
>
> Otherwise these things will keep their users in 1.1 land until they 
> are upgraded
>
>>>
> OK.  Would be interesting to see stats on rates of failure and why - 
> if you have any.
>
> Adrien
>
>
>>
>>
>> Regards,
>> Willy
>>
>>
>>
>
>

---

From: Mike Belshe <[email-masked]>
Date: Thu, 5 Apr 2012 16:33:23 -0700

> a lot of objects fit perfectly well inside a 64Kb UDP packet.

I would propose that HTTP only concern itself with reliable transports.  A
reliable transport provides both in-order delivery and guaranteed delivery.
 UDP does not provide guaranteed delivery (even if you use the 64K hack you
mention to avoid the in-order issues), and therefore is not a transport
worthy of discussion for HTTP/2.0 by itself.

Mike

---

From: David Morris <[email-masked]>
Date: Thu, 5 Apr 2012 17:00:59 -0700 (PDT)

> worthy of discussion for HTTP/2.0 by itself.

Yes ... I even wonder if HTTP itself should deal with the multiplexing or 
if HTTP should remain a request/response communication with the sorting 
out of multiple sub-streams handled by a lower layer. W/o a specification,
it is hard to be sure, but I think I'd implement two layers, even if
they arrive as a 'single layer' in the eventual spec.

---

From: Mike Belshe <[email-masked]>
Date: Thu, 5 Apr 2012 17:10:59 -0700

> they arrive as a 'single layer' in the eventual spec.

That's exactly how SPDY is spec'd - the framing layer (section 2) with the
binding for HTTP messages on top of it (section 3)

Mike

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 6 Apr 2012 14:00:11 +0000 (UTC)

Mike Belshe <mike@...> writes:

> For the record - nobody wants to avoid using port 80 for new protocols.  I'd
> love to!  There is no religious reason that we don't - its just that we know,
> for a fact, that we can't do it without subjecting a non-trivial number of
> users to hangs, data corruption, and other errors.  You might think its ok for
> someone else's browser to throw reliability out the window, but nobody at
> Microsoft, Google, or Mozilla has been willing to do that...

And yet none of those vendors though twice before disabling https redirects,
even though it was known they were widely used by proxies and captive portals,
and no replacement was proposed, and it subjected and still subjects a
non-trivial number of proxy users to hangs, data corruption, and
other errors.

-- 
Nicolas Mailhot

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 6 Apr 2012 14:18:46 +0000 (UTC)

> not saying they are not benefiting, but I've not seen the evidence.

Are you serious?

Take any IT net-zine, they post every few weeks about another corp getting
infected with various malware, and how much it is costing them

Compared to the cost of one such incident, passing smtp and http traffic through
an anti-malware gateway is as cheap as it gets (yes it is not perfect, but it's
a lot more reliable than praying every computer on the internal network is
properly secured)

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Apr 2012 16:30:29 +0200

On Fri, Apr 6, 2012 at 4:00 PM, Nicolas Mailhot <[email-masked]

>  I'd

I don't think this is relevant to the http/2.0 discussion. I'm happy to
have this discussion, but perhaps you should start another thread.

I don't know what you mean by disabling https redirects...I think you mean
clients do what they are supposed to do with https URLs - verify the
server's certificate, which generally prevents these captive portals from
MITM'ing the connection. I understand this causes problems for captive
portal vendors, but I don't think it's valid to complain that clients are
correctly implementing https. I think captive portal vendors should come up
with a real proposal instead of relying on hacks.

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 6 Apr 2012 14:33:29 +0000 (UTC)

Amos Jeffries <squid3@...> writes:

> IME admin are usually not that eager to do MITM on TLS.

Yes there are all sorts of unpleasant legal risks involved

> It is required by policy makers who just want to publish tick-box policies 

It is required to authenticate proxy users now that popular sites are moving to
ssl, since no one has defined a reliable way to do it without breaking tls.

And then once the system is in place who will vouch it won't be abused for
corporate follies?

It is *very* dangerous to make encryption an all-or-nothing proposal. That makes
it an everyone-has-a-reason-to-break-it system, which means it *will* be broken,
even in the cases it's perfectly justified.

If you want to add security to browsing make *very* sure there is little reason
for legal-abiding entities to break it, or they will finance and build the tools
criminals will use. That means using encryption sparingly, not as a blanket
system.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Apr 2012 16:43:07 +0200

On Fri, Apr 6, 2012 at 4:33 PM, Nicolas Mailhot <[email-masked]

> criminals will use. That means using encryption sparingly, not as a blanket

This logic makes no sense to me. I disagree strongly.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Apr 2012 17:12:27 +0200

> have this discussion, but perhaps you should start another thread.

It is very relevant to this discussion. Because of this browser decision,
https is currently broken in authenticating gateway environments. That is one
of the pain points http/2 should fix.

> I don't know what you mean by disabling https redirects...

Once upon a time, when a user navigated on an https web site, an intermediary
hop could send a redirection to its own authentication gateway to autorise the
user. And then browsers decided such redirects where evil (they could also be
used for MITM) and started to ignore them without providing any other
mechanism to handle gateway auth.

> I think you mean
> correctly implementing https.

That's very well written, except browsers deliberately broke a widely-deployed
use case, and didn't propose anything to replace it (and no one can replace it
without browser cooperation).

You won't get any sympathy from all the proxy admins which have been yelled at
those past years because some user got blocked while browsing an https web
site and could not understand the proxy had no way to get the f* browser to
display the normal proxy auth page (the biggest price goes to Firefox that in
addition to blocking the proxy redirects complains to the user the proxy is
blocking the connection and it does not know why)

> I think captive portal vendors should come up

The proposal has been made many times in browser bug trackers. It's always
basically:
1. web client requests a web page
2. gateway responds web client is not authorized (or authorized anymore) to
access this url, and specifies the address of its authentication page
3. web client displays this address (if it's a dumb client like curl) or
renders it (if it's a browser)
4. user authenticates
5. web client retries its first request and now it works

Happiness ensues as the user gets its page, the admin is not yelled at, and
corporate filtering is enforced.

The only thing changing between proposals are the error codes or field names,
the basic design is always the same.

And no various "I'm on the internet" test pages do not work since they do not
map to network topology nor to the filtering rules enforced by the gateway. In
fact such a page when implemented has a high chance to get summarily
blacklisted since browsers like to hammer it for no good reason all the time.

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Apr 2012 17:19:05 +0200

> This logic makes no sense to me. I disagree strongly.

I'm not making a logic point, I'm stating how things are moving now, from
direct experience. People have been blindly pushing for https everywhere those
past years without handling the pain points this caused to corporations, and
as a results lots of proxy providers are getting fat sums to break this
encryption now

(and btw browsers and google are not the only ones to blame, vendors like
Citrix that have told IT it could just tunnel citrix through https and network
admins would be none the wiser helped quite a lot too)

-- 
Nicolas Mailhot

---

From: Mike Belshe <[email-masked]>
Date: Fri, 6 Apr 2012 15:30:27 +0000

On Fri, Apr 6, 2012 at 3:19 PM, Nicolas Mailhot <[email-masked]

> >> for legal-abiding entities to break it, or they will finance and build
> the
> >> tools

This sounds great to me.  If it gets broken, we'll fix it.  No point in
pretending it is secure if it is really not.

I expect a lot of innovation in the CA verification / trust arena in the
next few years.  If you keep up on that side of the world - you'll see
there is a lot that can change very soon.  But this is a bit orthogonal to
HTTP/2.0.

Mike

---

From: Mike Belshe <[email-masked]>
Date: Fri, 6 Apr 2012 15:34:46 +0000

Once again - the people arguing against encryption are the people that want
to exploit the user's data transmission stream for their own personal gain.

If we want the Internet to be protect users - encrypt it.

If we want the Internet to be an enabler to vendors that want to
change/alter/slow down/trick users into seeing their content, buying their
products, etc, then don't.

It's a simple choice:  users vs interceptors.

Mike

On Fri, Apr 6, 2012 at 3:12 PM, Nicolas Mailhot <[email-masked]

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Apr 2012 17:52:09 +0200

> It's a simple choice:  users vs interceptors.

It's not.

On a corporation network the users are employees. Their employer does not owe
them unlimited access to facebook, youtube or various porn sites.

If filtering those breaks other network accesses because someone made war on
'interceptors' it's not the corporation which will be punished it's the
end-users trying to work through this breakage.

If their workstation breaks down because it got infected they won't thank you
for disabling the network antivirus gateway. In fact if the BYOD craze
succeeds, not only they will have to meet objectives despite computer
breakdown, but they'll also have to fix their computer themselves.

So may it result in some privacy loss? Maybe (though I'm sure most
corporations would be happy not to look at a user webmail or bank as long as
they could filter most of the rest). Do users care?  Facebook success says
they don't.

-- 
Nicolas Mailhot

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Apr 2012 18:07:27 +0200

On Fri, Apr 6, 2012 at 5:52 PM, Nicolas Mailhot <[email-masked]

> end-users trying to work through this breakage.

Haven't we been down this read already on this mailing list? Let's create
and use explicit trusted https proxies (if you don't know what I'm talking
about here, make sure you've read some of these megathreads from the past
week). If a corporation wants to force all employees to allow their content
to be filtered, then let them use a group policy to force browsers to
connect via this proxy and configure their firewall rules to disallow
direct access to the internet.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Apr 2012 17:39:43 +0100

On 04/06/2012 03:18 PM, Nicolas Mailhot wrote:
> Stephen Farrell<stephen.farrell@...>  writes:
>

Yes.

> a lot more reliable than praying every computer on the internal network is

Detecting/blocking inbound malware is a real requirement. I was asking
for evidence that such detection/blocking is happening because of
MITMing TLS.

Others were claiming that enforcing policy on outbound content was
a reason for this MITM. In that case, I don't buy that argument as
it happens, so was again asking for evidence.

I've seen assertions, and arguments, but not evidence.

S

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Apr 2012 17:42:12 +0100

On 04/06/2012 05:07 PM, William Chan (陈智昌) wrote:
> week).

I've read those and I don't know what precisely is meant.

I have doubts such a thing can be safely done in a way that'd
result in IETF consensus.

But, we won't know until someone writes the I-D describing
this.

S.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Apr 2012 18:54:27 +0200

> I've read those and I don't know what precisely is meant.

The browser connects to an explicitly configured HTTPS proxy (much like how
browsers can configure HTTP proxies today). Rather than using a CONNECT
tunnel, browsers issue a GET https://www.example.com, and the proxy does
the https transaction (SSL handshake, certificate validation, yada yada) on
the browser's behalf. That's why it's called "trusted", since you're
trusting this proxy to do that security sensitive stuff for you. There are
two missing pieces here. (1) need a way to provide integrity guarantees
(MACs or what not) on https content coming from the trusted proxy and (2)
need a way for browsers to figure out when to do https end-to-end or to
issue a GET https:// to a proxy (basically, do we want confidentiality or
not for this URL).

> result in IETF consensus.

I dunno, I thought that lots of the intermediary guys here seemed pretty
positive about it. I think everyone agrees transparent SSL MITM is lame.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Apr 2012 18:05:43 +0100

> issue a GET https:// to a proxy (basically, do we want confidentiality or

I see more than two missing pieces. For example, why would a bank
or healthcare web site find this acceptable, what about TLS client-
authentication, or even channel-bindings, how's the user or browser
know where the right proxy is at *all* times, how'd this work at
home, in an open hotspot etc. etc. The paragraph above does not
answer any of these questions, and its too much for any sensibly
sized email to answer:-)

I think this really really needs a worked out spec. I'm not saying
that's needed today, but IMO it's needed before it'd be safe to
assume that this approach will work and would garner IETF consensus.

S

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 6 Apr 2012 19:27:01 +0200

> answer any of these questions, and its too much for any sensibly

Fair enough :) I won't go address them one by one, but I think a good way
to think about it is that the current situation is, in certain cases,
people deploy transparent SSL MITM proxies which are evil. For the
situations where an organization may want to deploy one of these, we'd
rather they use an explicit trusted https proxy instead.

> assume that this approach will work and would garner IETF consensus.

OK.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 06 Apr 2012 17:30:23 +0000

In message <[email-masked]>

>to exploit the user's data transmission stream for their own personal gain.

Sorry Mike, but this totally black/white view doesn't work.

As I said earlier, there are users who are not legally allowed to
have end-to-end privacy, prison-inmates, children, employees etc.

You may disagree with these policies and/or their underlying
rationales, but if you make HTTP/2.0 incompatible with them, you
will just slow HTTP/2.0 deployment.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 6 Apr 2012 10:30:31 -0700

The proposal is: the resources served via SSL and which were requested with
the https scheme would return a signed description of the data being
returned as well as policy info from the site about mitm/trusted proxies.
The policy could be to allow certain content, to tunnel via connect through
it for other content, or to deny access.
The client would be the entity executing the signed policy.
If that policy isn't present and there is no explicit mitm, then the client
would do as it does for https today. If the policy is missing and there is
an mitm, the client must display an error to the user and refuse to proceed.

Anything which proposes auto configuration of a proxy would need some more
deep thought... but this problem is no different for hospitals, etc. than
it is today.
This is important. This problem exists today. The way I've seen it working
is that the captive portals refuse arbitrary access to any site but the
author site  through :443 until you've authenticated.

-=R
On Apr 6, 2012 10:07 AM, "Stephen Farrell" <[email-masked]>

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Fri, 6 Apr 2012 17:40:45 +0000

I would agree with this view. In fact, many of the arguments I have seen are explicitly not for personal gain but due to practical, legal, or other considerations that are not tied to personal gain in any way.

Thanks,

Henrik

-----Original Message-----
From: Poul-Henning Kamp [mailto:[email-masked]] 
Sent: Friday, April 06, 2012 10:30 AM
To: Mike Belshe
Cc: Nicolas Mailhot; "William Chan (陈智昌)"; [email-masked]
Subject: Re: multiplexing -- don't do it

, Mike Belshe writes:

>Once again - the people arguing against encryption are the people that 
>want to exploit the user's data transmission stream for their own personal gain.

As I said earlier, there are users who are not legally allowed to have end-to-end privacy, prison-inmates, children, employees etc.

You may disagree with these policies and/or their underlying rationales, but if you make HTTP/2.0 incompatible with them, you will just slow HTTP/2.0 deployment.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Apr 2012 18:43:24 +0100

> an mitm, the client must display an error to the user and refuse to proceed.

So we've a web site, a browser-side (hopefully!) middlebox and a
browser playing a "who's the TLS endpoint" game. I don't think
that's easy to get right in a secure (enough) way but I look forward
to reading the I-D.

S

> On Apr 6, 2012 10:07 AM, "Stephen Farrell"<[email-masked]>
> wrote:
>
>>
>>

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Fri, 6 Apr 2012 19:48:28 +0200

> author site  through :443 until you've authenticated.

This is the simplest configuration possible. Sometimes some :443 sites are
deliberately whitelisted for business reasons, which makes it real hard for
the user to identify why part of the web it accessible but not all
(and as long as browsers refuse to display anything not served by the :443
site there is no way for the proxy to explain the filtering policy)

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Apr 2012 21:37:42 +0200

Hi Mike,

> to exploit the user's data transmission stream for their own personal gain.

I disagree with your view here. I'm against mandatory encryption because there
are many places where it's not *needed* (eg: in the backoffice). And having two
different protocols for the same thing seems like the wrong solution to me,
while the model we currently have where HTTP is the framing protocol which
uses a transport whether it's encrypted or not ensures that encryption is used
only where appropriate.

Also, I know you disagree with me on the point of the performance cost, but I
have some haproxy users forwarding 10 Gbps of data 24*7 on a single machine by
relying on TCP splicing which consists in avoiding memory copies. These data
are files exchanged between some hosts and that are encrypted/decrypted on the
user's PC, which means that encrypting the transport just adds a useless second
encryption. You can forward at 10 Gbps right now on a single machine between 25
and 50% CPU. By simply switching from splice() to recv()+send(), you double the
CPU consumption. By adding decryption and encryption on top of that, you always
add more work than just recv()+send(), even if you're using crypto accelerators
etc... Forcing these services to apply encryption to data that are already
stored encrypted and resulting in a significant increase in infrastructure
costs is not going to help HTTP2 adoption at all, instead it will fragment the
web.

As we discussed last week, I'm sure that once we get HTTP to work over UDP,
it will be much cheaper to perform point-to-point encryption because it's
much cheaper to offload datagram encryption than stream encryption (basically
the NICs will do it for free). But doing encryption over TCP is expensive, at
least as much as several memcpy() of the same buffers, which precisely is what
we try to avoid as much as possible at high bit rates.

> If we want the Internet to be protect users - encrypt it.

Remember again, right now people who lose money on their bank account on
the Internet are already using end-to-end encryption. The issue has much
more to do with malware running on their host, and fortunately the issue
is less important in corporate networks because these malware are not
commonly allowed to communicate to the C&C server over HTTPS there !

If you want to protect internet users, do your best to stop malware !

> It's a simple choice:  users vs interceptors.

Interceptors are bad but they exist right now in part because of the lack
of ability to securely connect to a mandatory proxy. This certainly needs
to be addressed. They also exist because at some places it's not easy to
deploy a proxy configuration (eg: your smartphone might not support having
one in 3G, so your operator installs an accelerator to "improve" your
browsing experience).

We need to think why something which currently is an opt-in isn't proposed
to end users before trying to block the features that people had to invent
to solve this issue in the dirtiest way. Otherwise we'll fail again and
we'll see them invent even dirtier tricks to get the work done.

Regards,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Apr 2012 21:54:24 +0200

> for evidence that such detection/blocking is happening because of

We do have customers asking for this. Their reasoning is simple :
  - either I can ensure they don't bring malware in ;
  - or I block the site.

Some sites are generally slightly more trusted than other ones. For
instance, https to gmail, yahoo, amazon, paypal or banks is trusted
because they're expected to clean their contents. So you end up with
the classical 3-level filtering :

  - white-list a bunch of trusted sites
  - black-list a bunch of other sites
  - block all other ones or apply MITM if you can

Contrary to a common belief, large corporations don't care a dime what
you're saying via your webmails, simply because there is far too much
traffic to have anyone analyze it. What would you expect them to see
at 1000 req/s ~ 30-50 million req/day ?

They care about keeping their employees efficient at work, which means
ensuring they don't break their tool with malware, and they don't waste
their time on online games and social networks. Of course legal stuff
is applied too (block access to hate & porn sites).

Regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Fri, 6 Apr 2012 13:29:08 -0700

I'd imagine that Stephen has some knowledge in the area as well :)

> at 1000 req/s ~ 30-50 million req/day ?

That is a blanket statement that seems likely to be false given that I'd
guess that none of us has a comprehensive survey of all reasons that people
deploy these controls.

> is applied too (block access to hate & porn sites).

I can think of other motivations off the top of my head.
I believe it is sufficient to note that there is demand for proxies which
can do these things, and to provide each party in the communications chain
the ability to do what is necessary so long as it doesn't breach the user's
trust without the user's knowledge.

-=R

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Apr 2012 21:36:07 +0100

On 04/06/2012 09:29 PM, Roberto Peon wrote:
> doesn't breach the user's

Ideas for how to do that welcome;-)

Its UI stuff (and hence not an IETF thing really), but afaik,
we've (tech industry generally) failed miserably in informing
end-users about TLS.

Its not something we should try solve here, or construct
pre-conditions from, but equally we should be skeptical of
solutions where a well-informed end-user is needed. (And
that's implicit in some of the recent discussions here.)

S.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Apr 2012 22:40:35 +0200

Hi Roberto,

Agreed.

Users want to trust the network, and network admins want to be able to
trust users. Each one needs a level of control.

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 06 Apr 2012 20:48:54 +0000

>Ideas for how to do that welcome;-)

If we amend the proxy protocol as several has proposed, the endpoint
of trust for the user will be the proxy.

What happens after that point is entirely opaque to the user, and
it will have to be left to the user to decide if the proxy is
trustworthy.

The users browser can and SHALL inform him if he has privacy as
far as the proxy, but should also make it clear that the privacy
cannot be assured to extend any further.

I'm sure browser-writers can find a color-code for this.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 6 Apr 2012 23:14:24 +0200

> it will have to be left to the user to decide if the proxy is

In my opinion we should let the user decide between GET https:// and
CONNECT. That solves all issues because admins can let just a short
whitelist run on CONNECT, with the rest being analyzed.

Willy

---

From: Daniel Stenberg <[email-masked]>
Date: Fri, 6 Apr 2012 23:17:07 +0200 (CEST)

> whitelist run on CONNECT, with the rest being analyzed.

+1

CONNECT will "save" the users completely, yet GET https:// will be what lots 
of companies and orgnizations will want.

-- 

  / daniel.haxx.se

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 06 Apr 2012 21:26:08 +0000

>whitelist run on CONNECT, with the rest being analyzed.

For reasons of backwards compat, I don't think we'll get rid of
CONNECT any time soon, and since it is also widely used for getting
VPN out through corp perimeters, it will have to be supported by
proxies still.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 6 Apr 2012 15:14:52 -0700

> Ideas for how to do that welcome;-)

I'l be submitting a draft sometime next week about all of this, hopefully.

> that's implicit in some of the recent discussions here.)

Ah... I sometimes use user and useragent interchangably, when they're not.
:/
I expect to have the site be able to state its policy in a way which is not
easily spoofed by a proxy, and then to have the UA act upon that policy in
some reasonable way (where the definition of reasonable changes depending
on the scheme of the URL).

-=R

---

From: tom <[email-masked]>
Date: Sat, 7 Apr 2012 22:11:11 +0800

Hi Guys:

we studied on HTTP over UDP two years and implemented HTTPP scheme to run
HTTP over UDP on firefox.

attachment is HTTPP extension for firefox-11.0 on Win7.
once install it, if type
httpp://www.iwebpp.com:3000/<http://www.iwebpp.com/>will show:

Hello, iWebPP:
	This is Tom calling to Jagua from UDP.:)

and, when type http://www.iwebpp.com:3000/ <http://www.iwebpp.com/> will
show:

Hello, iWebPP:
	This is Tom calling to Jagua from TCP.:)

Best regards
  Tom

On Sat, Apr 7, 2012 at 3:37 AM, Willy Tarreau <[email-masked]> wrote:

> want

---

From: tom <[email-masked]>
Date: Sat, 7 Apr 2012 22:15:02 +0800

WARNING: contains banned part

Subject: Re: multiplexing -- don't do it
From: tom <[email-masked]>
To: Willy Tarreau <[email-masked]>
Cc: Mike Belshe <[email-masked]>, Nicolas Mailhot <[email-masked]>, "William Chan (?????????)" <[email-masked]>, [email-masked], jaguar xiong <[email-masked]>, Salvatore Loreto <[email-masked]>, [email-masked]
Date: Sat, 7 Apr 2012 22:15:02 +0800
List-Id: <ietf-http-wg.w3.org>

attach HTTPP firefox-11.0 win7 extension.

On Sat, Apr 7, 2012 at 10:11 PM, tom <[email-masked]> wrote:

> once install it, if type httpp://www.iwebpp.com:3000/<http://www.iwebpp.com/>will show:
>
> Hello, iWebPP:

---

From: patrick mcmanus <[email-masked]>
Date: Sat, 07 Apr 2012 11:21:38 -0400

cool. What did you learn from the project about the efficacy of udp?

On 4/7/2012 10:15 AM, tom wrote:
> On Sat, Apr 7, 2012 at 10:11 PM, tom <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Guys:
>
>     we studied on HTTP over UDP two years and implemented HTTPP scheme
>     to run HTTP over UDP on firefox.
>

---

From: tom <[email-masked]>
Date: Sun, 8 Apr 2012 01:17:24 +0800

we didn't really make any testbench for HTTPP by now. However, we tried
HTTPP to streaming  Movie with HTML5 video tag, it perform well.

AFAIK, run HTTP over UDP has two particular benefits:
1. easy to setup P2P communication between browsers like what WebRTC to do
2. leverage both HTTP power with UDP's performance for video/audio App
using HTML5 video/audio tag.

And, UDP is message-oriented, suppose doing HTTPP encryption or compression
is more efficient than stream-oriented transport like TCP.

Best regards
  Tom

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 7 Apr 2012 20:29:33 +0100

> corporate filtering is enforced.

That's quite broken if the request is an AJAX update or something
like that from an existing page on their browser, such as a page
they've kept open from before, or resumed from a saved session, or as
you say not authorized any more (presumably were earlier).

Transparent interception makes the page go wrong; the user is not
rendered happy in these cases.

-- Jamie

---

From: Jamie Lokier <[email-masked]>
Date: Sat, 7 Apr 2012 20:33:52 +0100

Jamie Lokier wrote:
> [too much]

(Apologies for accidentally quoting too much of the previous message.)

-- Jamie

---

From: David Morris <[email-masked]>
Date: Sat, 7 Apr 2012 13:36:53 -0700 (PDT)

> It's a simple choice:  users vs interceptors.

Not really, since my interception product is all about improving the
user's experience and in some way enabled by the user choosing to
use it, but to provide my services to https connections, I need
a way to let my infrastructure, implemented as a proxy, securely
share the reponsiblity for implementing the encryption.

---

From: Peter Lepeska <[email-masked]>
Date: Sat, 7 Apr 2012 16:37:48 -0400

HTTP over UDP also allows us to imagine the speed ideal -- a two round trip
web page load, one request for root/click request and concurrent requests
for all contained objects. If this is done over a reliable UDP each object
can have independent packet accounting so problems retrieving it anywhere
along the path has no impact on other objects. It's the fastest, most
robust way to load a page. Pages without content inter-dependencies, super
large objects, slow javascripts, and fast web servers (a lot of ifs I know)
could load on first time visits in under 100 ms over high bandwidth, low
latency networks. Nice!

Of course there are lots of new problems created by moving away from a
connection-oriented transport in general and TCP in particular but this was
a question about the advantages.

Peter

On Sat, Apr 7, 2012 at 1:17 PM, tom <[email-masked]> wrote:

> And, UDP is message-oriented, suppose doing HTTPP encryption or
> compression is more efficient than stream-oriented transport like TCP.
>
> Best regards
>   Tom
>
>
>>> we studied on HTTP over UDP two years and implemented HTTPP scheme to
>>> run HTTP over UDP on firefox.
>>>
>>
>>
>

---

From: Roberto Peon <[email-masked]>
Date: Sat, 7 Apr 2012 15:33:43 -0700

On Sat, Apr 7, 2012 at 1:37 PM, Peter Lepeska <[email-masked]> wrote:

> HTTP over UDP also allows us to imagine the speed ideal -- a two round
> trip web page load, one request for root/click request and concurrent
> requests for all contained objects.

The ideal is actually one round trip, plus page_bytes/link_bandwidth.

> If this is done over a reliable UDP each object can have independent
> packet accounting so problems retrieving it anywhere along the path has no
> impact on other objects. It's the fastest, most robust way to load a page.
> Pages without content inter-dependencies, super large objects, slow
> javascripts, and fast web servers (a lot of ifs I know) could load on first
> time visits in under 100 ms over high bandwidth, low latency networks. Nice!
>
There are very large and scary beasts in the waters of the unexplored
country of defining an application-layer transport without regard to larger
factors such as... not crashing the internet, and that is without
considering how to deal with packet loss :)

I'd propose that, while such things are interesting, solving a transport
problem is decidedly not in scope of the WG.

-=R

Peter

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 07 Apr 2012 22:40:16 +0000

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Peter Lepeska" <[email-masked]>;"Mark Nottingham" 
<[email-masked]>
Cc: "tom" <[email-masked]>;"patrick mcmanus" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 8/04/2012 10:33:43 a.m.
Subject: Re: multiplexing -- don't do it
> HTTP over UDP also allows us to imagine the speed ideal -- a two 
> round trip web page load, one request for root/click request and 
> concurrent requests for all contained objects.

  If this is done over a reliable UDP each object can have independent 
  packet accounting so problems retrieving it anywhere along the path 
  has no impact on other objects. It's the fastest, most robust way to 
  load a page. Pages without content inter-dependencies, super large 
  objects, slow javascripts, and fast web servers (a lot of ifs I know) 
  could load on first time visits in under 100 ms over high bandwidth, 
  low latency networks. Nice!  
  Of course there are lots of new problems created by moving away from 
  a connection-oriented transport in general and TCP in particular but 
  this was a question about the advantages.  
 
 There are very large and scary beasts in the waters of the unexplored 
 country of defining an application-layer transport without regard to 
 larger factors such as... not crashing the internet, and that is 
 without considering how to deal with packet loss :)
 
 I'd propose that, while such things are interesting, solving a 
 transport problem is decidedly not in scope of the WG.
+1
  
UDP can be quite interesting for certain custom applications in 
controlled environments.  But throw in routers, firewalls and the 
internet, and it's just not reliable enough... esp considering UDP 
datagram fragmentation.
  
Adrien
>  we didn't really make any testbench for HTTPP by now. However, we 
>  tried HTTPP to streaming  Movie with HTML5 video tag, it perform 
>  well.
>  
>  2. leverage both HTTP power with UDP's performance for video/audio 
>  App using HTML5 video/audio tag.
>  
>  On Sat, Apr 7, 2012 at 11:21 PM, patrick mcmanus <[email-masked]> wrote:
>   > we studied on HTTP over UDP two years and implemented HTTPP 
>   > scheme to run HTTP over UDP on firefox.
  > 
 > 
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 07 Apr 2012 22:43:18 +0000

also... UDP is very problematic for DoS, since there's no established 
connection, and therefore no verification of source.  
  
Try defending yourself against a DNS flood with spoofed source and 
you'll see what I mean.  The work you need to do to respond to an HTTP 
request is typically a lot more than you need to do for DNS, so the 
impact would be worse.
  
So IMO it's completely unsuitable as a transport for HTTP over the 
internet.

Adrien

------ Original Message ------
From: "Roberto Peon" <[email-masked]>
To: "Peter Lepeska" <[email-masked]>;"Mark Nottingham" 
<[email-masked]>

 

 -=R
 
  Peter

   AFAIK, run HTTP over UDP has two particular benefits:
   1. easy to setup P2P communication between browsers like what WebRTC 
   to do
   2. leverage both HTTP power with UDP's performance for video/audio 
   App using HTML5 video/audio tag.
   
   And, UDP is message-oriented, suppose doing HTTPP encryption or 
   compression is more efficient than stream-oriented transport like 
   TCP.
   
   Best regards
     Tom
   
   On Sat, Apr 7, 2012 at 11:21 PM, patrick mcmanus <[email-masked]> wrote:
    cool. What did you learn from the project about the efficacy of 
    udp?

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sat, 07 Apr 2012 23:03:26 +0000

In message <emc784be85-d0e8-4ced-8785-15a6435fe0f4@BOMBED>, "Adrien W. de Croy"

>connection, and therefore no verification of source.  

Yes, I see little role for HTTP over UDP outside controlled environments
for this reason.

But in controlled environments, the benefits can be quite large,
as for instance, the example I keep hearing about:  A caching
surrogate (= Varnish) in front of webservers with lots and lots and
lots of small objects.

There is no relevant packet loss, there are no hostile actors and
object size can be infered from URI

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sat, 07 Apr 2012 23:11:02 +0000

I agree it's very interesting for cases like this.
  
I guess though unless enough people want to do it, and interoperate, 
then people will just do it custom until someone gets around to writing 
a profile for UDP.
  
Adrien

------ Original Message ------
From: "Poul-Henning Kamp" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Roberto Peon" <[email-masked]>;"Peter Lepeska" 
<[email-masked]>;"Mark Nottingham" <[email-masked]>;"tom" 
<[email-masked]>;"patrick mcmanus" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 8/04/2012 11:03:26 a.m.
Subject: Re: Re[2]: multiplexing -- don't do it

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 8 Apr 2012 13:04:52 +0200

> you say not authorized any more (presumably were earlier).

No that's not quite broken that's the only way it can work.

Please admit that on restricted networks access to some external sites
requires authorization. That this authorization won't be eternal for basic
security reasons. That due to hibernation/resume/client mobility/plain
equipment maintenance this authorization will need to be acquired or
reacquired at any point in the web client browsing. That means yes you do need
to handle ajax updates, mid-of-tls-interruptions, and all the difficult use
cases. The user is not going to oblige you by restricting himself to the
simple use cases when auth needs reacquiring

Because if web clients don't handle those, the gateway will always have the
option to block the access. And make no mistake it will and does exercise it.

The refusal to handle those cases so far has resulted in :
1. broken hotel/conference captive portals
2. widespread availability of TLS interception in proxy manufacturer catalogs
3. corporations getting stuck on old insecure browser versions because the
newer ones 'security' hardening broke their proxies
4. corporations hand-patching newer browser releases to restore the old
'redirection on https works' behaviour

And in all those cases, who were the first to suffer? The users. If you'd poll
them the vast majority would care *nothing* about the https cleanliness model,
privacy, etc. Not as long that means they have a broken browsing experience
everyday long. Beca

Lots have been written here about the great anger of corporate overlords
reading their employees messages, and the need to harden the website-to-user
channel. But you know what?

1. corporate overlords by an large do not care bout their employee's browsing
as long as they are productive
2. if a rotten corporate apple had delusions about spying on its people, it
would use an external team not its own network people (specialized criminal
shops are so much more discreet and effective than normal network people)
3. in all the cases I've seen so far where an employee was punished for
something he did on the net, the leak came from the web site, not the company
network systems (why set up a complex intercepting system when users – even
including supposedly sophisticated people like lulz – brag openly of their
misdemeanors on public social sites)

-- 
Nicolas Mailhot

---

From: Jamie Lokier <[email-masked]>
Date: Mon, 9 Apr 2012 16:12:10 +0100

Nicolas Mailhot wrote:
> reacquired at any point in the web client browsing.

I'm not arguing against the authorization requirement.

I'm only saying that your "happiness ensues" conclusion is false, as
you did say the proposal is always basically the same, and in my
personal experience as an end user, it's horrible already.

> That means yes you do need to handle ajax updates,
> mid-of-tls-interruptions, and all the difficult use cases. The user
> is not going to oblige you by restricting himself to the simple use
> cases when auth needs reacquiring Because if web clients don't
> handle those, the gateway will always have the option to block the
> access. And make no mistake it will and does exercise it.

Right.  But the web client _can't_ handle those cases, because the
gateway is injecting a fake redirect, the gateway doesn't know what
it's interrupting, and the result is just like a normal page, not an
error page or special signal to the browser asking for authorization.

> everyday long.

Here's what happens in the old style: I connect to
corporate/hotel/cafe network.  Then I dread starting Firefox because
my last 50 open tabs will start up and _all_ redirect to the portal's
Wifi login page.  I get 50 stupid login pages, and lose the original
state.

If I'm paying attention, I start Firefox _before_ connecting to the
network, wait for it to start in offline mode and load the 50 tabs
correctly, and then connect to the network.

But still, those pages which are using AJAX polling start doing random
things, as their Javascript gets something random it wasn't expecting.

These days I resort to running w3m (a Lynx-like text-only browser) to
go the proxy's login page first.  But that's increasingly broken too,
as some Wifi login pages have stopped being normal forms, and only
work in a fully fledged graphical browser with Javascript enabled, to
"simulate" form fieleds.  Don't ask me why.  All I know is the model
you are pushing is broken enough with HTTP.

So my objection to the classical approach to authorization by
redirecting everything has nothing to do with security, or even HTTPS,
and everything to do with the user experience.

What would work much is if the browser got a response meaning "you
will need to authorize before the original request can proceed - open
[URL] to present an authorization page", and do not consider the
original request to have completed yet.

Intercepting proxies could do that with HTTP or HTTPS or HTTP/2.0 if
there's a standard signal for it, *without* having to break the
security model or mislead any users.  It would be a nicer experience
for everyone.

-- Jamie

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 10 Apr 2012 10:31:05 +0900

Hello Jamie, others,

Mark had a draft on this, 
http://tools.ietf.org/html/draft-nottingham-http-portal-02. I'm not sure 
why it didn't move forward.

Regards,   Martin.

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 10 Apr 2012 08:47:41 +0200

> error page or special signal to the browser asking for authorization.

Then it needs to be handled at the protocol level here.

>> 1. broken hotel/conference captive portals
[…]

> Wifi login page.  I get 50 stupid login pages, and lose the original

That's your browser being intentionally stupid (especially in all the cases it
knows it's behind a proxy since it already had a pac to read), hoping that by
being stupid enough captive portals will go away. That didn't work too well so
far.

> and everything to do with the user experience.

The user experience is bad because browser people broke the old ways of doing
things, forcing equipment people to resort to more and more dangerous hacks

> original request to have completed yet.

Which is exactly what proxy people have been demanding for years.

> security model or mislead any users.  It would be a nicer experience

So let's put this in HTTP/2, ok ?

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 10 Apr 2012 09:00:29 +0200

> why it didn't move forward.

I think it morphed in http error 511 however:

1. error 511 does not return an url so it can't be handled by dumb web clients
such as curl
2. browser people do not like it. Gateway auth really needs to be specified
once and for all in a document with browser buy-in such as http/2

-- 
Nicolas Mailhot

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 10 Apr 2012 09:03:53 +0200

> once and for all in a document with browser buy-in such as http/2

To clarify, unless hop-to-hop auth is clearly integrated from the start in the
protocol model, browser people will say it is bolted afterwards and breaks
this model, will try to get away not implementing it and things will continue
to be massively broken.

-- 
Nicolas Mailhot

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 12:11:13 +0200

> why it didn't move forward.

It has been replaced by draft-nottingham-http-new-status, which will be 
published as RFC very soon.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 12:12:37 +0200

> 1. error 511 does not return an url so it can't be handled by dumb web clients

Nor did the proposal in draft-nottingham-http-portal-02. Also, handling 
by dumb web clients was never on the agenda for this code, and I'm also 
not sure how it's supposed to work.

> once and for all in a document with browser buy-in such as http/2

Please do not make blanket statements like these unless you can back 
them up.

Best regards, Julian

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Tue, 10 Apr 2012 13:03:10 +0200

> not sure how it's supposed to work.

As started on the curl or git list dumb clients can not render a complex auth
page. They could give the user the address of this page, so he could open it
in a smarter client, if they had this address available in the HTTP 511
headers.

http://lists-archives.com/git/763532-handle-http-error-511-network-authentication-required-standard-secure-proxy-authentification-captive-portal-detection.html

> Please do not make blanket statements like these unless you can back

Right now http/1 is perceived as an end-to-end protocol with no provision for
intermediaries. And the situation is worse with TLS. If http/2 adds
multiplexing, this multiplexing should make it explicit intermediaries exist
and make a channel available for intermediaries to add their signalling

Right now what browser people have written about error 511

| Doing something "useful" with 511-over-MITMed-SSL would mean a huge increase
| in attack surface:
| * We'd have to poke a hole all the way through our TLS stack to even see the
| 511.

| A new HTTP status code won't help this bug because we get the SSL certificate
| name mismatch error before we can send an HTTP request.

(the "end-to-end" only argument)

| 3. We determine, from that error, whether we think we should try to detect
| the captive portal. If so, we issue a request to captive-portal
| test-mozilla.org. If that response comes back as a 511, or with a wispr
| response, or some other indication that we're in a captive portal, then we
| kick into captive portal mode.

(the "let's ignore proxy signalling and try to guess location by our own"
argument)

| But, I don't think we should avoid implementing a solution for the most
| common cases just because there are a few (or even many) cases where it
| wouldn't work.

("it's hard, let us do it some other day" argument)

It's a hard problem which had no satisfactory answer so far and which
resolution has been postponed for all of http/1 life. Please do not make the
same mistake with http/2 and provide for intermediaries from the start up.

https://code.google.com/p/chromium/issues/detail?id=71736
https://bugzilla.mozilla.org/show_bug.cgi?id=728658

Best regards,

-- 
Nicolas Mailhot

---

From: Julian Reschke <[email-masked]>
Date: Tue, 10 Apr 2012 13:42:11 +0200

> http://lists-archives.com/git/763532-handle-http-error-511-network-authentication-required-standard-secure-proxy-authentification-captive-portal-detection.html

The URI is the request URI.

> https://bugzilla.mozilla.org/show_bug.cgi?id=728658

It seems that you are looking for a solution for a complex problem. 511 
is just a simple building block that is supposed to make it more obvious 
for captive portals to return an HTTP response with a status code other 
than 2xx. As such, it can be deployed right away, and browsers *can* 
make use of it as well.

Best regards, Julian

---

From: Salvatore Loreto <[email-masked]>
Date: Tue, 10 Apr 2012 17:38:43 +0200

I concur with Robert that solving a transport problem is decidedly not 
in scope of the WG.

however I can not resist ...

> connection, and therefore no verification of source.
right, but you can use DTLS for this
> So IMO it's completely unsuitable as a transport for HTTP over the 
but you can use SCTP over DTLS over UDP can provide an interesting 
solution to investigate from a *research prospective*
SCTP in the userland provide you with natively MUX and congestion 
control, and the userland approach solve the fact that not all the OSs 
support SCTP;
DTLS provides you with security
UDP: encapsulation of SCTP over UDP allows also to pass through NAT

/Sal

-- 
Salvatore Loreto, PhD
www.sloreto.com

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 13 Apr 2012 15:11:46 +1200

On 8/04/2012 11:11 a.m., Adrien W. de Croy wrote:
> then people will just do it custom until someone gets around to 
> writing a profile for UDP.

That would be CoAP wrappings AFAICT.

AYJ

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 13 Apr 2012 16:24:08 +1200

> and make a channel available for intermediaries to add their signalling

That perception is plain wrong. HTTP/1 has always had the definition of 
a proxy built-in as much as SMTP has the concept of a relay built-in.

The *T* in TLS does not alter the hop-by-hop nature. That is an 
illusion. Even CONNECT can and does traverse multiple hops from the 
tunnel endpoint to the origin destination.

> (the "end-to-end" only argument)

The reality more often than not being:

    A =>B=>C->D

A makes CONNECT through B to "endpoint" C. C relays to D. D responds 
through C to A.

When B requires authentication ... only Basic and Kerberos seem to work 
nicely.
When B requires all inbound requests be made over TLS connections ... 
only Chrome seems to work easily.

> (the "let's ignore proxy signalling and try to guess location by our own"

Your brief summary says it all really. If they dont trust the endpoint 
they are connected to at least signal its own needs and location 
properly, what hope is left? The person using this argument would be 
terrified by ARP spoofing.

> same mistake with http/2 and provide for intermediaries from the start up.

We are required to maintain semantic compatibility with HTTP/1. 
Proxy-auth headers remain in all proposals. Pity the browser who dont 
implement them for captive portals.

The argument from the captive portal people is simply to get browsers to 
pay attention to portal / proxy signals and act as if the portal 
existed. Stop complicating things by pretending end-to-end for 
everything (including TLS port 443) even when the protocol signals are 
clear and loud that a proxy exists in the middle.

When the nay-sayers can get over that paradigm shift even HTTP/1 will be 
able to work better.

AYJ