Subject: HTTP2 Expression of Interest

From: Doug Beaver <[email-masked]>
Date: Sun, 15 Jul 2012 03:38:35 +0000

This is Facebook's response to the call for expressions of interest
in HTTP/2.0: http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2CfI

1. Introduction

Facebook's mission is to give people the power to share and make the
world more open and connected.  Our web and mobile applications are
used by well over 900 million users worldwide.

At Facebook, we serve HTTP/1.1 from a globally distributed
infrastructure that operates at large scales.  We are interested in
sharing our experiences and plan to actively participate in the
development of HTTP/2.0.

We currently are implementing SPDY/v2, due to the availability of
browser support and the immediate gains we expect to reap.  Although
we have not run SPDY in production yet, our implementation is almost
complete and we feel qualified to comment on SPDY from the
implementor's perspective.  We are planning to deploy SPDY widely at
large scale and will share our deployment experiences as we gain them.

The remainder of this response presents a protocol-neutral summary of
what we need in the next generation of HTTP, followed by an assessment
of each of the three current HTTP/2.0 proposals.

2. Criteria for the Next Version of HTTP

In order to provide faster and more secure online services to our
users, the features we need in HTTP/2.0 are:

  * Multiplexing
  * Transport layer encryption
  * Zero-latency upgrade
  * Per-request flow control
  * Server push

2.1 Multiplexing

Like many large web companies, we have invested in content packaging
mechanisms to reduce the number of round trips required to download a
web page.  While this has worked reasonably well for us, we see two
problems:

  * Many of the best practices in web performance optimization - for
    example, image spriting and domain sharding - are workarounds for
    HTTP 1.1's lack of widely-usable pipelining.  The next version of
    the HTTP should fix that.
  * The complexity of these workarounds has limited their adoption.
    We want the whole web to be faster, not just our own site.

Thus we recently rebuilt our internal HTTP framework to support
multiplexing of many independent requests per connection, and we plan
to use this framework to support SPDY and the eventual HTTP/2.0
standard.

2.2 Transport layer encryption

We feel strongly that HTTP/2.0 should require transport encryption,
and we acknowledge that this position is potentially controversial.

RFC 2616 likely will be at least 15 years old by the time HTTP/2.0 is
ratified.  Comparing the Internet of today to the Internet of the late
1990s, two trends stand out:

  * The sophistication and surface area of attacks have grown
    dramatically.
  * The Internet user community has grown steadily, from a niche
    in 1999 to a third of the world's population in 2012.

We can't forecast what the Web will look like in 10-15 years, but
based on history we can assume that more and more personal information
will be flowing between users and applications, and that the user
population will continue to grow.

Mandating transport layer encryption will make things harder for
implementors such as ourselves, but in return it will offer greater
privacy and safety to the billions of people who use the Web today and
in the years to come.  We think this is a good thing.

At present, TLS is the pragmatic choice for encrypting the transport
due to its widespread implementation in the existing Web
infrastructure. We do not see the need to mandate TLS itself; if there
is an improved protocol in the future that supports both
authentication and encryption, that would be fine to use as well.

Regarding our deployment experience, we have deployed TLS at a large
scale using both hardware and software load balancers. We have found
that modern software-based TLS implementations running on commodity
CPUs are fast enough to handle heavy HTTPS traffic load without
needing to resort to dedicated cryptographic hardware. We serve all of
our HTTPS traffic using software running on commodity hardware.

2.3 Zero-latency upgrade

Some of the current HTTP/2.0 proposals use the HTTP/1.1 Upgrade header
to negotiate the use of HTTP/2.0.  We prefer the TLS NPN extension,
because it allows the immediate use of HTTP/2.0 on a newly established
TLS connection without an additional network round trip for the
upgrade.

2.4 Per-request flow control

HTTP proxying is an inherent part of our large, distributed
infrastructure.  The ability to multiplex HTTP streams from many
clients into a shared upstream transport is good for performance,
especially if there is a high network latency between the proxy and
the upstream server.  But different clients will produce and consume
data at different rates, so it is important to have per-stream flow
control.

2.5 Server push

We provide real-time, user-to-user text messaging on multiple
platforms via multiple protocols.  For HTTP clients, we use long
polling and streamed, chunked responses (one chunk per message) as a
lowest common denominator solution.  This solution works, but it moves
a lot of protocol processing complexity into client-side JavaScript.
We are interested in the development of a standardized server push
mechanism to replace long polling in HTTP/2.0

A subtle but important requirement for applications such as web-based
chat is that data sent from the server must be pushed without delay.
We would like to see the inclusion in HTTP/2.0 of a "no buffering"
flag at either the message or the chunk level, to indicate to the
recipient and any intermediaries that the flagged content should not
be delayed for buffering or I/O-coalescing purposes.

3. Assessment of the HTTP/2.0 Proposals

3.1 SPDY

We are implementing SPDY and plan to deploy it widely in two roles:
speaking HTTP directly to users, and enabling faster communication
between geographically distant web servers on our network. Of the
three proposals, we believe it is the best basis for further work due
to the variety of client and server implementations, its proven usage
at large scale, and its full support for our HTTP 2.0 criteria.

Assessment using our criteria:

  * Multiplexing: supported
  * Transport layer encryption: While SPDY currently does not
    require an encrypted transport, current client implementations
    implement SPDY over TLS.
  * Zero latency upgrade: TLS NPN -- not required by the current
    SPDY draft, but used by current implementations -- allows the
    negotiation of SPDY or HTTP/1.1 with no extra network round
    trips.
  * Per-request flow control: supported in SPDY/3
  * Server push: supported

Additional considerations:

Of the three HTTP/2.0 proposals, SPDY currently is the one with the
largest user base, due to its inclusion in Firefox 13 and Chrome.

SPDY's header compression is a good, general-purpose solution, and
gzip is a good starting point, but we would prefer to see a more
lightweight compression algorithm for the HTTP/2.0 standard.

3.2 HTTP Speed+Mobility

We have not implemented HTTP Speed+Mobility, and we currently do not
plan to implement it. There is no sizable deployment of either clients
or servers, and it is missing features we feel are required.

Assessment using our criteria:

  * Multiplexing: supported
  * Transport layer encryption: missing
  * Zero latency upgrade: missing
  * Per-request flow control: supported
  * Server push: missing, but highlighted as a recommended area
    for additional development

Additional considerations:

HTTP Speed+Mobility's dependence on the HTTP Upgrade header is a
problem for us because it adds an additional network round trip in a
very common use case: loading several small, static resources from a
CDN.  Section 1.4 of the HTTP Speed+Mobility proposal notes the need
to tunnel the WebSockets stream over TLS when there is an
"incompatible proxy" (i.e. a proxy not known to support HTTP/2.0)
between the client and server.  We agree, and therefore the following
comparison uses TLS:

  * SPDY: 4 x RTT minimum elapsed time to fetch N resources on a
    new connection (without TLS session resumption or False Start) :
    TCP handshake plus 2 RTT for TLS handshake with NPN, plus
    1 RTT to fetch the resources.
  * HTTP Speed+Mobility: 5 x RTT minimum elapsed time: TCP handshake,
    2 RTT for TLS handshake, 1 RTT to fetch the first resource via
    HTTP/1.1 with "Upgrade: websocket," and 1 RTT to fetch the
    remaining N-1 resources.

3.3 Network-Friendly HTTP Upgrade

We have not implemented Network-Friendly HTTP Upgrade, and we
currently do not plan to implement it, due to the incompleteness of
the specification and the lack of client implementations.

Assessment using our criteria:

  * Multiplexing: supported
  * Transport layer encryption: missing
  * Zero latency upgrade: missing
  * Per-request flow control: missing; Section 2 suggests that
    this is a TBD item
  * Server push: missing

Additional considerations:

Network-Friendly HTTP Upgrade uses a Transport Header Frame to
communicate headers that will be the same for every request on the
connection.  While this is a good solution for the connection between
a browser and a load balancer it does not work between the load
balancer and an upstream web server, where requests from different
clients may be multiplexed onto the same connection.

The use of a registry for well-known header field names would allow
for compact encoding of those names, but we foresee interoperability
problems as new fields are added.  A client will not be able to use
the assigned numeric code for a new field without knowing whether the
server also knows about it.

4.0 Summary

We at Facebook are enthusiastic about the potential for an HTTP/2.0
standard that will deliver enhanced speed and safety for Web users.

Of the three proposals, we recommend the use of SPDY as the basis for
development of the HTTP/2.0 specification, but feel that the
requirement for a secure transport must be added. We plan to continue
developing and optimizing our HTTP, TLS, and SPDY implementations and
are deploying them on a global scale. We look forward to sharing our
experiences with the community.

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 15 Jul 2012 08:35:04 +0200

Hello Doug,

I have a few comments and questions below.

> in the years to come.  We think this is a good thing.

I don't want to start the encryption debate in this thread, but since you
have a fairly balanced approach, I'd like to note that at the moment, almost
100% of stolen user information is been done on encryption-protected services,
whether it is bank account credentials or webmail credentials or information.
The issue always comes from malware running on the PC, infecting the browser
and stealing the information at the human interface. However, users feel
safer because they see the SSL lock. And it's not always the browser, as
there was a report of stolen webmail information in TLS traffic in a certain
country when a CA was broken and new certs for a number of large sites were
emitted.

Also, you said that it could make things harder for you, but did you
evaluate only the front access or also the protocol used between your
load balancers and backend servers ? I'm asking because there is a
difference between mandating the use of encryption in browsers and
designing the protocol based on this. For instance, WebSocket has the
masking flag mandatory on upstream traffic but the protocol supports
not having it between servers.

Basically, since all sensible sites already make use of TLS, I don't think
we can make them safer by mandating use of TLS for them. However mandating
use of TLS will make it harder to work on the backend, it will very often
be a counter-productive effort which increases costs a lot (cert managing,
troubleshooting, etc) with no added benefit.

(...)
> be delayed for buffering or I/O-coalescing purposes.

I think that what you're describing here precisely is what WebSocket
offers, but I may be wrong, depending on your precise use-cases. It
implicitly offers server push in the sense you're describing it (push
of any data, not HTTP objects), and automatically offers the no-buffering
flag because when HTTP gateways switch to WebSocket, they know this
is interactive traffic and stop buffering. I think your description
confirms the need to unify the transport layer to support both HTTP
and WS at the same time in the same connection.

> the specification and the lack of client implementations.

Note that its incompleteness was intentional as it was not meant to be
a complete proposal but just to study alternative compression and upgrade
schemes only.

>   * Transport layer encryption: missing

Encryption only relies on the transport layer here so that we can still
support non-encrypted traffic between servers (think webservices etc...).

>   * Zero latency upgrade: missing

A solution for this is presented in paragraph 5 of the spec. Zero latency
upgrade is mandatory in my opinion, we cannot afford to waste one round
trip on mobile terminals. As it is suggested, the protocol also supports
zero-latency fallback, which is equally important in the many environments
which won't support HTTP/2 at the beginning : you don't want to waste a
round trip to retry on HTTP/1 when you see the HTTP/2 connection has failed.

> clients may be multiplexed onto the same connection.

In recent works, we have noted that this offers minimal benefit. Basically,
you'd have only the Via and Host headers, which is useless. However, we
also know that what flows between a load balancer and a server is much
less sensible to latency. Right now this is almost always 1 or 10 Gbps
connectivity through a single switch. Our recent experiments have shown
that we can get rid of this transport header classification without making
a compromise on performance.

> server also knows about it.

It's just a matter of protocol versioning. We already have a registry of
HTTP headers and it works well enough. An HTTP version would mandate one
encoding and clients would respect this encoding. For tentatively new
headers, they would be sent in clear text form until the connection
suggests that the version is high enough to send them in raw form. Also,
it has apparently worked well for WAP and I think that we could restart
from this encoding instead of reinventing a fresh new one (maybe it needs
a bit of refreshing though).

Best regards,
Willy

---

From: James M Snell <[email-masked]>
Date: Sun, 15 Jul 2012 00:28:29 -0700

On Sat, Jul 14, 2012 at 11:35 PM, Willy Tarreau <[email-masked]> wrote:

> [snip]
For the sake of discussion, use of a numeric code does not necessarily
introduce an interop challenge if must-ignore semantics are employed and
clearly spelled out. Assume, just for illustrative purposes, that we have
an IANA registry of headers. Each is assigned a numeric value and a code
page, represented by a single 16-bit integer. The first 4-bits represent
the code page, the remaining 12-bits represent the specific registered
header within the page. This should give us WAY more than enough room for
growth for new headers

 [0000] [0000 0000 0000]
  (CP)        (ID)

Let's also assume that the registrar is responsible for assigning the
specific ids to the header on a first-come-first-serve basis (unlike the
current scheme employed for status codes where spec authors just kind of
guess at one to use).

Now, let's say that code page 0 represents Registered "Must Understand"
headers. These are ones that tend to be critical to the basic operation of
the protocol, where failure to properly handle them could cause significant
issues. Code pages 1-9 represent registered "Must Ignore" headers... these
are ones that are known to be safe to ignore if they are not understood.
Code pages 10-15 are private use, with 10 being reserved for "Must
Understand" Private headers and the rest being must ignore. Everything in
the >= 10 range does not get registered, but applications would run the
risk of conflicts.

Suppose an application sends a message that contains a new CP#1 header that
the recipient does not understand. Seeing that it's CP#1, and seeing that
it's incapable of understanding the header, the server can reject the
message. However, suppose the application sends a message containing a new
CP#2-9 header or CP#11-15 header. If the server doesn't understand the new
header, it simply ignores it. If the application sends a new CP#10 header
that the server doesn't understand, the server rejects it.

Following such a scheme, clients or servers would be able to make use of
new header id's without having to know in advance if the header is
supported. There are, of course, a number of issues that could arise out of
this kind of scheme, but overall it should demonstrate that the use of
numeric codes does not necessarily impede interoperability.

The one significant area where it could fall apart is on
HTTP/2.0<==>HTTP/1.1 conversion, where the intermediary has to be able to
map the numeric identifiers to specific text labels. If the intermediary
sees a new CP#1 header that it doesn't understand and can't map, it would
have no choice but to return an error. If, however, it sees a header within
a must-ignore CP, and it's not able to map that header, it could either (a)
drop it silently or (b) provide some alternative generic encoding for that
header and let the recipient attempt to sort it out.

- James

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Jul 2012 08:08:48 -0400

I can't see a value to mandating use of TLS in HTTP/2.0. There might
be an argument for requiring support for TLS but even that represents
a layer violation. But almost no Web browsers lack support for TLS.
Mandating use of or support for TLS in HTTP/2.0 is only going to have
a coercive effect if people are forced to stop using HTTP/1.1 which
isn't possible.

TLS is only as secure as the credentials used to secure it. If you
have weak credentials you have weak security. The strength of a
credential really depends on whether the credential is making a
statement about the real-world holder: Is this facebook.ru certificate
really for a corporation with officers that would be on the hook if
they did something criminal or was it issued to the Russian maffia who
have grabbed the local domain name?

Confidentiality is actually a very minor direct requirement in most
security sensitive systems. Having the Russian maffia look at my bank
account matters much less to me than having them modify it.

The underlying concern here seems to be that we need to move from a
situation where security is optional on the Internet to where security
is the default. I very much endorse that requirement but simply
mandating TLS in HTTP/2.0 does not get us there unless clients have a
way to know that a site is offering  HTTP/2.0

In short what we really need is a policy mechanism that enables a
client to know whether a site supports TLS and/or HTTP/2.0. This is
what I have been working on with my Omnibroker proposal and my DNS
security policy extensions.

Using the DNS to effect security policy means opening up a can of
worms. Even though the DNS is the authoritative source for making
statements about DNS names, direct access to the unfiltered DNS is not
available on many networks. DNSSEC has still to prove it is more than
a science project. We need to define the right policy statements and
it might take us more than one try. And finally, and most importantly,
authoritative DNS statements are not necessarily safe ones. I do not
want my browser to visit sites controlled by the Russian maffia even
if they did pay ICANN for their domain name.

That is why I have developed Omnibroker which allows the client to use
a simple, stable interface that does not require it to do more than
ask a service 'how should I connect to site X with protocol Y'. The
question is then answered by a service chosen by the user to meet
their security concerns.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 15 Jul 2012 12:27:56 +0000

In message <CAMm+LwjYUjpELfi=t3UAOXBYUWWuFD08df58rPvg3Wx=[email-masked]>
, Phillip Hallam-Baker writes:

>I can't see a value to mandating use of TLS in HTTP/2.0. 

Lets move it back one step further:

There is negative value in mandating crypto in HTTP/2.0 because it
will make HTTP/2.0 unattractive to the people who refer to themselves
as "in the multimedia business".

These people deliver about 1/3-1/2 half of all HTTP traffic on the
Internet in a fetching range of skin-tones.

Please don't try to push political agendas, like mandatory encryption,
with technical means.

It doesn't work.

-- 
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: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 15 Jul 2012 09:12:30 -0400

TLS is not an appropriate security solution for the content delivery
people. No question about that.

But they do have security concerns and they could benefit from the
right security solution, one that allows them to use pre-baked crypto.
IE a message layer security solution rather than a transport layer
solution.

Let us imagine that Viacom stores all their movie content in encrypted
and authenticated form. When someone wants to watch one they pull the
encrypted bits from the server, wrap the relevant key so that the
intended recipient can read them and ship them out to the user.

This allows Viacom to protect their intellectual property with almost
no performance impact.

If all we needed for this was the content layer piece it would be a
no-brainer. message level encryption is just another encoding. We
already have a PKI for TLS to provide public keys. The devil comes in
the key exchange to join the two together.

-- 
Website: http://hallambaker.com/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 15 Jul 2012 13:27:35 +0000

In message <CAMm+Lwh44tHq=QmQo_0VXazMHNGaHrd8L0zzjGYScy-=[email-masked]>
, Phillip Hallam-Baker writes:

>right security solution,

Of course HTTP/2.0 should provide good quality crypto solutions.

Forcing people to use them however, would be plain stupid.

---

From: Doug Beaver <[email-masked]>
Date: Tue, 17 Jul 2012 22:11:41 +0000

Hi Willy,

Thank you for your reply.

I should note that Facebook's EOI was written by myself and Brian Pane; Brian
is the lead engineer on our SPDY efforts and has been doing a lot of work to
prepare our HTTP stack for multiplexed operation. Brian has thought more about
some of your protocol questions than I have, so I think he'll step in and
offer his thoughts.

I have some thoughts on the encryption issue which I'll share below. These
thoughts aren't the official position of Facebook, they are my own opinion.

Hopefully my reply will answer most of the questions that have been raised on
this thread though.

> 100% of stolen user information is been done on encryption-protected
> services, whether it is bank account credentials or webmail credentials or
> information.  The issue always comes from malware running on the PC,
> infecting the browser and stealing the information at the human interface.
> However, users feel safer because they see the SSL lock. And it's not always
> the browser, as there was a report of stolen webmail information in TLS
> traffic in a certain country when a CA was broken and new certs for a number
> of large sites were emitted.

Here's my thoughts on mandating transport encryption:

  * The SSL/TLS/CA ecosystem is flawed, but it's the most widely deployed
    system we have for securing web traffic. We shouldn't let the flaws in the
    current system stop us from advocating for more user privacy; in fact
    greater pressure on the CA system from a crypto mandate would probably
    lead to reforms there.

  * SSL/TLS doesn't do a lot to address targeted attacks against one user
    (e.g. malware, spear-phishing, etc) but it helps guard against
    surveillance and censorship of large user populations. While there are
    weaknesses with the CA system that make it possible for governments and
    organizations to issue rogue certs in targeted cases, it is very difficult
    to deploy rogue certs globally for all web traffic for all users. Put
    simply, the more widely that SSL/TLS is used, the greater chance that
    users will have privacy in their online communications.
    
  * SSL/TLS stops "helpful" transparent proxies from intercepting your
    unencrypted traffic and doing things with it that you didn't ask them to.
    Encryption keeps these proxies honest, all they can do is choose whether
    or not to forward your connection. 

  * Symmetric crypto costs are not much higher; I think Akamai quoted 10-20%
    in their response. I think the costs aren't a big deal for major sites; if
    you are large enough to care about performance, you are large enough to
    support session resumption, which cuts out the CPU cost of most
    handshakes. Rather, it's a much more interesting question for the very
    small operators and very small embedded devices. For example, if I have a
    thermostat in my fridge that wants to report temperature and power usage
    information somewhere central, it might be onerous to require it to speak
    crypto in order to talk to a web server today. I just think that it won't
    be onerous tomorrow.

  * Monetary cost of the certs is not an issue. You can get free (or cheap) DV
    certs, so hobbyist sites and non-profits would not be locked out from the
    web due to lack of access to cheap certs, and even if they were, I expect
    the market will produce a CA whose costs will meet that user demand. For
    EV cert prices, I expect that the market will continue to optimize those;
    there has been a steady decline in EV cert prices over the years. Either
    way, if you're large enough to require an EV cert, you have other
    infrastructure costs to bear as well (power, rent, hardware, network
    connectivity, domain registration, etc).

The Internet has always been about the (mostly) free expression of ideas, both
in terms of monetary cost and personal freedom in what you can say. I actually
think it's pretty amazing that we have the Internet at all; if you look at all
the civilizations that have existed in human history, not many of them would
have built something that offered so much freedom for people to communicate
with each other and publish their ideas and beliefs. However, we now live in a
time where a sizable fraction of humanity uses the Web to communicate daily,
and that makes those people a very lucrative target.

I also think it is useful to understand why people object to the idea of
mandated transport encryption as well. Critiques include the extra resource
usage, the high cost of certs, the extra round trips, and the broken CA system
(to name a few), while others react against the idea of forcing a mandate
itself and thus having protocols push political agendas.

I think all those positions can be valid. I just happen to think that even
given all the above, it is still better to mandate encryption and give better
privacy to Internet users than it is to punt the ball down the field another
twenty years.

> evaluate only the front access or also the protocol used between your load
> balancers and backend servers ? I'm asking because there is a difference
> between mandating the use of encryption in browsers and designing the
> protocol based on this. For instance, WebSocket has the masking flag
> mandatory on upstream traffic but the protocol supports not having it
> between servers.

Regarding load balancers and resource usage, we looked at three cases:

  * Traffic between LB and user
  * Traffic between LB and LB
  * Traffic between LB and web server

For the LB<->user case, you can remove a lot of handshakes with session
resumption. We are seeing a 80% hit rate for our session caching deployment
which supports server side session caching and client side session tickets.
Plus, I would expect that multiplexed protocols hold onto their client sockets
longer since you expect a higher probability of reusing that socket later
(since you've gone from N connections to a given domain to just one
connection). So you end up mostly just paying the symmetric cipher cost.

The LB<->LB case happens when you terminate a user on an edge node close to
them (say London) and tunnel their request to a remote datacenter. This speeds
up the TCP and SSL handshakes since those happen over a low RTT link. If you
advertise HTTPS capability to your users, it's obvious that you want to speak
HTTPS between the LB in London and the end user in Liverpool. It is perhaps
less obvious that you also need to encrypt the link between your edge LB in
London and your datacenter in the US, since that traffic will travel over
circuits leased from major carriers (unless you lay your own transoceanic
fiber, and even then, there are techniques for tapping undersea traffic
cables).

For the LB<->LB case, you tend to use persistent connections, so the handshake
cost is low. This is especially true with multiplexed protocols since you can
fit so much traffic on those sockets; much more traffic than you're ever going
to fit on a single LB<->user connection. So for these connections, you're
mainly paying the cost of the block level cipher versus the more costly
handshake.

Once you get inside the datacenter, encryption is less important since you
don't have to worry as much about third parties intercepting that traffic.
Still, one would imagine that the datacenter load balancer would still
probably keep persistent connections to the web servers it was balancing its
load across and would enjoy similar handshake amortization as the other two
cases.

So I actually think that the sites with the largest request loads have the
hardest time being against TLS on the resource usage front, especially when
you look at the low cost of running TLS on commodity hardware and the expected
gains in hardware power over the coming years.

I'm more concerned about very small devices that want to use HTTP to report
usage statistics (thermostats, pressure monitors, industrial sensors, etc).
They might not be able to afford the hardware power to perform TLS. I think
any personal communication devices (feature phones, smart phones, tablets,
laptops, desktops, etc) will always have enough CPU to handle crypto, or will
have onboard ASICs that they can offload that crypto to.

> use of TLS will make it harder to work on the backend, it will very often be
> a counter- productive effort which increases costs a lot (cert managing,

Requiring TLS definitely makes backend work more difficult but I think the
tools will come. A side-effect would probably be that web servers and load
balancers would get better instrumentation. I think Varnish has a nice
implementation with its shared memory ring buffer that's used to log events;
you can attach tools to that region and read the events in realtime as the
proxy operates. The model is quite good.

Regarding added benefit, it's true that many major sites are forcing HTTPS
already. However, many are not, and there's also a very long tail of
unencrypted sites out there. I argue that the added benefit is quite large.

> I think that what you're describing here precisely is what WebSocket offers,
> but I may be wrong, depending on your precise use-cases. It implicitly
> offers server push in the sense you're describing it (push of any data, not
> HTTP objects), and automatically offers the no-buffering flag because when
> HTTP gateways switch to WebSocket, they know this is interactive traffic and
> stop buffering. I think your description confirms the need to unify the
> transport layer to support both HTTP and WS at the same time in the same
> connection.

Brian Pane has thoughts on WebSocket and SPDY, and I think he can better
comment here.

Regards,

Doug

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Jul 2012 15:31:40 -0700

Pulling a really important paragraph out of Doug’s (long) posting, in
the hope that more people will thus read it.

> privacy to Internet users than it is to punt the ball down the field another

What he said. -T

---

From: Grahame Grieve <[email-masked]>
Date: Wed, 18 Jul 2012 08:36:36 +1000

>> privacy to Internet users than it is to punt the ball down the field another

 so, even when used in an internal application protocol, it's going to
 be end to end
 encrypted to make it super hard to debug? http is about more than users using
 web browsers.

 Grahame

---

From: James M Snell <[email-masked]>
Date: Tue, 17 Jul 2012 15:53:38 -0700

Mandatory end-to-end encryption does not make sense. There are countless
scenarios where TLS just isn't necessary. Yes, we can do a better job but
forcing it to be used in scenarios where there is no PII at risk is just
pointless.

- James

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 16:43:44 -0700

> > privacy to Internet users than it is to punt the ball down the field

+2

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 02:03:44 +0000

If the only down-side to mandating crypto was that some links that 
didn't really need it had to implement it, I wouldn't be so strongly 
against it.

But there are scenarios where crypto for HTTP is either impossible, 
illegal, or highly undesirable.

Mandating it is simply incompatible with reality.

------ Original Message ------
From: "James M Snell" <[email-masked]>
To: "Tim Bray" <[email-masked]>
Cc: "Doug Beaver" <[email-masked]>;"Willy Tarreau" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 18/07/2012 10:53:38 a.m.
Subject: Re: HTTP2 Expression of Interest
>Mandatory end-to-end encryption does not make sense. There are 
>countless scenarios where TLS just isn't necessary. Yes, we can do a 
>better job but forcing it to be used in scenarios where there is no 
>PII at risk is just pointless. 
>- James
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 18 Jul 2012 11:35:57 +0900

Hello Doug, everybody,

On 2012/07/18 7:11, Doug Beaver wrote:

>      in their response. I think the costs aren't a big deal for major sites;

Just a quick question: I think if we could shave off 10-20% of the 
bandwidth with some new technique, we'd all go for it.

So why are we okay with 10-20% more processing costs for everybody, but 
not with 10-20% more bandwidth? What's different between processing 
costs and bandwidth?

Regards,   Martin.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 17 Jul 2012 20:17:01 -0700

On 17 July 2012 19:35, "Martin J. Dürst" <[email-masked]> wrote:
> So why are we okay with 10-20% more processing costs for everybody, but not
> with 10-20% more bandwidth? What's different between processing costs and
> bandwidth?

Personally, I thought that the first optimization was for latency,
with bandwidth as secondary and (obviously) consequential.  Trade-offs
may have to be made.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 03:20:09 +0000

------ Original Message ------
From: "Martin Thomson" <[email-masked]>
>Personally, I thought that the first optimization was for latency,
How do you optimise latency by adding 3 RTs in a SSL setup?

---

From: Rajeev Bector <[email-masked]>
Date: Tue, 17 Jul 2012 20:26:56 -0700

Arguably, the cost of 3 Rts is amortized over many many objects that gets transferred over the session. That said, I am trying to imagine how to do crypto on my Arduino :-).

From: "Adrien W. de Croy" <[email-masked]<mailto:[email-masked]>>
Reply-To: "Adrien W. de Croy" <[email-masked]<mailto:[email-masked]>>
Date: Tue, 17 Jul 2012 20:20:09 -0700
To: Martin Thomson <[email-masked]<mailto:[email-masked]>>, "Martin J. Dürst" <[email-masked]<mailto:[email-masked]>>
Cc: Doug Beaver <[email-masked]<mailto:[email-masked]>>, Willy Tarreau <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re[2]: HTTP2 Expression of Interest

------ Original Message ------
From: "Martin Thomson" <[email-masked]<mailto:[email-masked]>>
On 17 July 2012 19:35, "Martin J. Dürst" <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 03:34:07 +0000

we can already transfer many objects over a single connection with 
HTTP/1.1

SPDY without SSL would be more speedy than with it.

There may be only a couple R-Ts to get an SSL handshake, but sprinkle 
on a CRL / OCSP check and you're left eating dust.

So, let's just get this straight for the record.  SSL will not improve 
latency.  It will make it worse, and for many people (on 
already-high-latency links) a LOT worse.

------ Original Message ------
From: "Rajeev Bector" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>;"Martin Thomson" 
<[email-masked]>;"Martin J. Dürst" <[email-masked]>
Cc: "Doug Beaver" <[email-masked]>;"Willy Tarreau" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 18/07/2012 3:26:56 p.m.
Subject: Re: Re[2]: HTTP2 Expression of Interest
>Arguably, the cost of 3 Rts is amortized over many many objects that 
>gets transferred over the session. That said, I am trying to imagine 
>how to do crypto on my Arduino :-).   
>
>
>From: "Adrien W. de Croy" <[email-masked]>
>Reply-To: "Adrien W. de Croy" <[email-masked]>
>To: Martin Thomson <[email-masked]>, "Martin J. Dürst" <[email-masked]>
>Cc: Doug Beaver <[email-masked]>, Willy Tarreau <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 20:43:19 -0700

On Tue, Jul 17, 2012 at 8:34 PM, Adrien W. de Croy <[email-masked]> wrote:

>
> we can already transfer many objects over a single connection with HTTP/1.1
>
> There may be only a couple R-Ts to get an SSL handshake, but sprinkle on a
> CRL / OCSP check and you're left eating dust.
>

Of course, no-SSL is lower latency than SSL.  It's not 3 RTs all the time,
but yes, OSCP can add a lot, and SSL implementations vary.  But SPDY gains
a lot of this back with fewer connections, multiplexing, and compression.
 Don't forget to implement SSL False Start in your client.  Obviously an
un-optimized SSL stack will have a harder time than an optimized one.

But its not true that every bit of latency is more important than security.

Note that Google has reported overall latency of SPDY + SSL is faster than
HTTP without SSL or SPDY.

Mike

> To: "Adrien W. de Croy" <[email-masked]>;"Martin Thomson" <
> [email-masked]>;"Martin J. Dürst" <[email-masked]>
> Cc: "Doug Beaver" <[email-masked]>;"Willy Tarreau" <[email-masked]>;"
> [email-masked]" <[email-masked]>
> gets transferred over the session. That said, I am trying to imagine how to
> do crypto on my Arduino :-).
>
>
> From: "Adrien W. de Croy" < <[email-masked]>[email-masked]>
> Reply-To: "Adrien W. de Croy" < <[email-masked]>[email-masked]>
> To: Martin Thomson < <[email-masked]>[email-masked]>,
> "Martin J. Dürst" < <[email-masked]>[email-masked]>
> Cc: Doug Beaver < <[email-masked]>[email-masked]>, Willy Tarreau < <[email-masked]>
> [email-masked]>, " <[email-masked]>[email-masked]" <<[email-masked]>
> [email-masked]>
> From: "Martin Thomson" < <[email-masked]>
> [email-masked]>
>
> On 17 July 2012 19:35, "Martin J. Dürst" < <[email-masked]>
> [email-masked]> wrote:
>
>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 20:44:15 -0700

> bandwidth with some new technique, we'd all go for it.

Symmetric crypto (RC4) is super super cheap - a couple of XORs - definitely
not 10-20% of CPU.  I'd like to see that measured again before taking
action upon it.  Obviously, if you use expensive crypto (presumably because
you want it), some algorithms take more CPU

mike

> not with 10-20% more bandwidth? What's different between processing costs
> and bandwidth?
>
> Regards,   Martin.
>
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 03:50:07 +0000

------ Original Message ------
From: "Mike Belshe" [email-masked]

> So, let's just get this straight for the record.  SSL will not 
> improve latency.  It will make it worse, and for many people (on 
 
 Of course, no-SSL is lower latency than SSL.  It's not 3 RTs all the 
 time, but yes, OSCP can add a lot, and SSL implementations vary.  But 
 SPDY gains a lot of this back with fewer connections, multiplexing, 
 and compression.  Don't forget to implement SSL False Start in your 
 client.  Obviously an un-optimized SSL stack will have a harder time 
 than an optimized one.
 
 But its not true that every bit of latency is more important than 
 security.
I'm just not convinced this would be a security win in the end.

How many CAs are there?  We may as well right now deprecate OCSP / CRL 
checks, because you have 200 million sites using a cert from one 
vendor, you take out their OCSP server(s), and you've taken down 200 
million sites.

Way to go amplifying DOS effectiveness.
Becoming a CA is non-trivial.  If we suddenly need a million more of 
them to cope with cert load, how do you anticipate that will improve 
security?  I think it will make for a disaster.

>
>Note that Google has reported overall latency of SPDY + SSL is faster 
>than HTTP without SSL or SPDY.  
you saying SPDY + SSL faster than SPDY (presumably without SSL)?  
Doesn't seem possible.

I have no problem accepting SPDY + SSL would be faster than HTTP.  But 
we're talking about adding a bunch of things to HTTP that would provide 
the same benefits that SPDY currently enjoys.

> To: "Adrien W. de Croy" <[email-masked]>;"Martin Thomson" <[email-masked]>;"Martin J. Dürst" <[email-masked]>
> Cc: "Doug Beaver" <[email-masked]>;"Willy Tarreau" <[email-masked]>;"[email-masked]" <[email-masked]>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 20:56:45 -0700

On Tue, Jul 17, 2012 at 8:50 PM, Adrien W. de Croy <[email-masked]> wrote:

> On Tue, Jul 17, 2012 at 8:34 PM, Adrien W. de Croy < <[email-masked]>
> [email-masked]> wrote:
>
>>
>> There may be only a couple R-Ts to get an SSL handshake, but sprinkle on
>> a CRL / OCSP check and you're left eating dust.
>>
> checks, because you have 200 million sites using a cert from one vendor,
> you take out their OCSP server(s), and you've taken down 200 million sites.
>
> Becoming a CA is non-trivial.  If we suddenly need a million more of them
> to cope with cert load, how do you anticipate that will improve security?
> I think it will make for a disaster.
>
>

The TLS concerns are legitimate.  We need to fix TLS to be even better, not
make HTTP/2 weaker.

> you saying SPDY + SSL faster than SPDY (presumably without SSL)?  Doesn't
> seem possible.
>

Oh - SPDY over port 80 is non deployable for the same reasons pipelining
isn't deployable.  So that will never happen :-)

But you're correct, I wouldn't expect SPDY + SSL to be faster than SPDY.

> we're talking about adding a bunch of things to HTTP that would provide the
> same benefits that SPDY currently enjoys.
>

Yeah, that's not going to fly....

The problem is that the intermediaries just get stuck (they expect that
port 80 is exclusively HTTP/1.1).  When you send them additional data, they
sometimes hang, and this prevents deployment of new protocols.  Websockets
has the same problem.  This is part of why no major sites are turning on
websockets on port 80....

But, regardless, SPDY gives us the window of opportunity through reduced
latency to add security into the protocol without making latency worse.

Mike

>> From: "Rajeev Bector" < <[email-masked]>[email-masked]>
>> To: "Adrien W. de Croy" < <[email-masked]>[email-masked]>;"Martin
>> Thomson" < <[email-masked]>[email-masked]>;"Martin
>> J. Dürst" < <[email-masked]>[email-masked]>
>> Cc: "Doug Beaver" < <[email-masked]>[email-masked]>;"Willy Tarreau" <<[email-masked]>
>> [email-masked]>;" <[email-masked]>[email-masked]" <<[email-masked]>
>> [email-masked]>
>> From: "Adrien W. de Croy" < <[email-masked]> <[email-masked]>
>> [email-masked]>
>> Reply-To: "Adrien W. de Croy" < <[email-masked]> <[email-masked]>
>> [email-masked]>
>> To: Martin Thomson < <[email-masked]><[email-masked]>
>> [email-masked]>, "Martin J. Dürst" < <[email-masked]><[email-masked]>
>> [email-masked]>
>> Cc: Doug Beaver < <[email-masked]> <[email-masked]>[email-masked]>, Willy Tarreau
>> < <[email-masked]> <[email-masked]>[email-masked]>, " <[email-masked]><[email-masked]>
>> [email-masked]" < <[email-masked]> <[email-masked]>
>> [email-masked]>
>> From: "Martin Thomson" < <[email-masked]><[email-masked]>
>> On 17 July 2012 19:35, "Martin J. Dürst" < <[email-masked]><[email-masked]>
>> not

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Jul 2012 23:59:56 -0400

RC4 is cheap but SHA2 is not.

Encryption without authentication is worthless. The principal security
objective in TLS is to provide integrity, not confidentiality. If you
lose integrity you are going to lose confidentiality even with 128 bit
encryption.

RC4 is a stream cipher. It is fast but thats about all that can be
said in its favor. If I care about confidentiality I am not going to
want a stream cipher.

On Tue, Jul 17, 2012 at 11:44 PM, Mike Belshe <[email-masked]> wrote:
>
>
> On Tue, Jul 17, 2012 at 7:35 PM, "Martin J. Dürst" <[email-masked]>
> wrote:
>>
>> Hello Doug, everybody,
>>
>>
> not 10-20% of CPU.  I'd like to see that measured again before taking action
> upon it.  Obviously, if you use expensive crypto (presumably because you
> want it), some algorithms take more CPU
>
> mike
>
>>
>>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:16:57 -0700

> said in its favor. If I care about confidentiality I am not going to

I believe RC4 is excellent for almost all cases.  It is certainly used on
millions of sites today just fine.

If the alternative is no security (e.g. arguing for no TLS), we can
probably agree that RC4 is more secure than that! :-)  Obviously, if you
want even stronger security, you can opt in to using other crypto
algorithms - those are configurable through TLS today.  No problem.
Requiring TLS with HTTP/2.0 would not need to require an expensive
symmetric crypto algorithm.

Mike

> action
> costs

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 00:26:08 -0400

While use of port 443 and TLS may be a practical requirement for use
of SPDY under certain network constraints, a protocol requirement is a
very different matter.

It should be obvious that a protocol be capable of deployment under
common network contraints but that does not mean that every
implementation of the protocol MUST implement or use the work-around.

Nobody is even being very clear about the precise nature of the
requirement 'must implement TLS' and 'must use TLS' are very different
criteria. There is only one precedent for requiring implementation of
a security protocol in a non security protocol that I am aware of and
that is IPv6 which is hardly an inspiring precedent. I cannot think of
any case where a non security protocol has mandated use of encryption.

TCP is a very small protocol stack and HTTP is not much bigger.

TLS is a huge protocol stack and should not be implemented by people
who don't know what they are doing. We actively discourage
proliferation of crypto stacks in the security area these days.

PKIX is a big, complicated spec that has technical, legal and policy facets.

TLS requires PKIX, you can't have one without the other. So mandating
TLS in HTTP/2.0 is really mandating TLS+PKIX. If people don't want to
rely on CAs for their trust anchors they will also need DNS, DNSSEC
and DANE.

On Tue, Jul 17, 2012 at 11:56 PM, Mike Belshe <[email-masked]> wrote:
>> but yes, OSCP can add a lot, and SSL implementations vary.  But SPDY gains a
>> lot of this back with fewer connections, multiplexing, and compression.
>> checks, because you have 200 million sites using a cert from one vendor, you
>> take out their OCSP server(s), and you've taken down 200 million sites.
>>
>> to cope with cert load, how do you anticipate that will improve security?  I
>> think it will make for a disaster.
>>
>
>
> The problem is that the intermediaries just get stuck (they expect that port
> 80 is exclusively HTTP/1.1).  When you send them additional data, they
>>> Arguably, the cost of 3 Rts is amortized over many many objects that gets
>>> transferred over the session. That said, I am trying to imagine how to do
>>> crypto on my Arduino :-).
>>>
>>>
>>> Cc: Doug Beaver <[email-masked]>, Willy Tarreau <[email-masked]>,
>>> "[email-masked]" <[email-masked]>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 00:33:21 -0400

No, RC4 is almost NEVER used on its own as you seem to imagine.

What is used is actually RC4 + SHA1. And the real security value
actually comes from the integrity check, not the stream cipher.

For HTTP/2.0 you would be much better off using AES-GCM which does
encryption and integrity in one operation.

On Wed, Jul 18, 2012 at 12:16 AM, Mike Belshe <[email-masked]> wrote:
> If the alternative is no security (e.g. arguing for no TLS), we can probably
> agree that RC4 is more secure than that! :-)  Obviously, if you want even
> stronger security, you can opt in to using other crypto algorithms - those
> are configurable through TLS today.  No problem. Requiring TLS with HTTP/2.0
> would not need to require an expensive symmetric crypto algorithm.
>
> Mike
>
>
>
>
>>
>>
>>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:38:56 -0700

> any case where a non security protocol has mandated use of encryption.

I thought everyone was talking about "must use TLS".

> PKIX is a big, complicated spec that has technical, legal and policy

I basically agree with this, yes.

Except most can get this from their operating system.  It's provided for
free in windows, macos, ios, and I believe android (but I have to check).

> rely on CAs for their trust anchors they will also need DNS, DNSSEC

CA trust anchors are policy, not implementation.

I would propose do what other protocol specs do, which is to leave policy
to the implementations.

Mike

> on
> time,
> vendor, you
> them
>  Doesn't
> the
> port
> gets

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 21:43:02 -0700

> No, RC4 is almost NEVER used on its own as you seem to imagine.
If you've ever looked at OpenSSL's config, you probably know they just call
it "RC4+MEDIUM" or something like that.  I was merely using the shorthand.

> actually comes from the integrity check, not the stream cipher.

Yes, this is what Google uses.

> encryption and integrity in one operation.

I'm not sure why this is better than RC4, when the author of this thread
was suggesting we should use no encryption at all.

Mike

> probably
> >> >>>    * Symmetric crypto costs are not much higher; I think Akamai
> quoted
> >> >>> 10-20%
> >> >>>      in their response. I think the costs aren't a big deal for
> major
> >> >>> sites;
> >> >>
> >> >>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 00:58:16 -0400

My lightbulbs have HTTP stacks and run web services. If I want to
modify the lighting, I send them a command to dim, brighten, change
the color balance or whatever.

They do not have an operating system or anything like it. That would
require a much bigger chip and a much higher current drain when not in
use.

The world of HTTP is a lot more than just Web browsers.

Mandating TLS in 2.0 will not provide an ounce of extra security
unless you have a way to know who is running 2.0. And if you can do
that you do not need the mandate.

On Wed, Jul 18, 2012 at 12:38 AM, Mike Belshe <[email-masked]> wrote:
> I would propose do what other protocol specs do, which is to leave policy to
> the implementations.
>
> Mike
>
>
>>
>>
>>
>>
>>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 01:03:00 -0400

AES is a block cipher and they are a lot more resistant to protocol
design issues.

RC4 was a barely acceptable approach in 1994 when it was first adopted
in SSL 1.0. It is really not an acceptable cipher in 2012.

On Wed, Jul 18, 2012 at 12:43 AM, Mike Belshe <[email-masked]> wrote:
> I'm not sure why this is better than RC4, when the author of this thread was
> suggesting we should use no encryption at all.
>
> Mike
>
>
>>
>>
>>

---

From: Mike Belshe <[email-masked]>
Date: Tue, 17 Jul 2012 22:13:55 -0700

> The world of HTTP is a lot more than just Web browsers.

There was a time, long ago, when people were flabbergasted by the idea that
you'd use HTTP to control your lightbulb too.  "I have to put an HTTP stack
on a lightbulb?  I could just use UDP!"  I suggest we design for the
future, not the past.

> that you do not need the mandate.

It's all negotiated in the handshake.  You'll know who is TLS and who is
not.

It does provide lots of better security.  The internet cafe is the best
example.  I know you're aware of Firesheep.  We should make it impossible
to use firesheep in 2020.  Right?

Mike

> improve
> >> > The TLS concerns are legitimate.  We need to fix TLS to be even
> better,
> >> > not
> >> > make HTTP/2 weaker.
> >> >
> >> >>
> >> >>
> >> >>> transferred over the session. That said, I am trying to imagine how
> to
> >> >>> do
> >> >>> with 10-20% more bandwidth? What's different between processing
> costs
> >> >>> and
> >> >>> bandwidth?
> >> >>>
> >> >>>
> >> >>>

---

From: Roberto Peon <[email-masked]>
Date: Tue, 17 Jul 2012 22:45:15 -0700

> SPDY without SSL would be more speedy than with it.

Assuming you could deploy it successfully and reliably to everyone, which
is not a trivial matter.

> already-high-latency links) a LOT worse.

SSL transforms something which is potentially not deployable into something
which is eminently deployable.
If the thing which is now deployed is able to amortize that cost, the
result may be a net benefit.
You're right that the first-order effect of SSL is to add RTTs to the
initial handshake.
You're neglecting the second-order effects.
-=R

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 08:18:39 +0200

> to use firesheep in 2020.  Right?

Mike, till now you've made serious arguments. But quite frankly, firesheep
is just a joke to send the usual summer end-of-the-world alert to the press.
I think none of us knows anybody who's been victim of this, because where it
would have mattered, TLS would have been used anyway.

I'm concerned about the situations where users' security is really attacked,
which is massive MITM using fake certs, massive bank accounts and credentials
collection using malware, spyware returning your browsing history to ads
vendors, and more recently malware running on smartphones to collect a lot
of personal information.

Mandating use of TLS is irrelevant to these real world issues and can only
make them worse. However I agree it will feel good to say "hey look, now I
can show you that firesheep doesn't see my cleartext password anymore",
but what site would require me to send my password in cleartext over the
net anyway ?

Regards,
Willy

---

From: Mike Belshe <[email-masked]>
Date: Wed, 18 Jul 2012 00:04:47 -0700

> would have mattered, TLS would have been used anyway.

Or maybe you just don't know.

> vendors, and more recently malware running on smartphones to collect a lot

Your argument is basically this one:

"Dear GMail user,  Congratulations!  You no longer need a password to
access your account!  Because hackers have infiltrated TLS, we realize it
is not secure anyway.  Therefore, we've decided to remove all passwords so
that it is as easy for you to access your email as it is for the hackers.
 Enjoy the new service!"

I know there are a lot of types of bad guys.  I know there are a lot of
people pessimistic about TLS (me too!).  But that doesn't mean that we take
all security out of protocols.

Server authentication can and does work.  It will get even better once we
start using it everywhere.

Lets be clear:  TLS is more work.  It's harder.  It requires everyone to do
more than they do today.  It requires more tools.  It requires more
optimizations.  But it is absolutely better than where we stand now.  We
can make this work - it will take a lot of great engineering, but it can be
done!  Don't be so pessimistic as to say "aw, shucks, we can't do it"  - I
know for a fact we can.

Let's vote in favor of the users, and fix the problem.  Protocols can and
must be secured.  Where they are not, we secure them more.  If TLS is not
secure enough, we make it more secure too.  Mandating TLS for HTTP will not
be the end of this road - it is just the beginning.  But until we take
steps to secure the world, it can never happen.  Let's do this!!!

> but what site would require me to send my password in cleartext over the

Its not usually about passwords - its about cookie hijacking - going
straight into their sessions and accessing all their info.  Steal the
cookie and you're in.

Mike

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 09:27:06 +0200

> that it is as easy for you to access your email as it is for the hackers.

No it's unrelated. My argument is that the sensible services are already
TLS enabled and still are already facing the limits of this model. Security
people in banks are already saying that they're considering that their users
are browsing in clear text since TLS doesn't secure them *at all* right now.
They have to invent many mechanisms to prevent malware from stealing passwords
and injecting operations. Where is there any privacy in this model ?

And when a number of webmail accounts were recently suspected of having been
broken after a CA cert break-in, there was no way for the poor user to suspect
that his "https://" in front of the URL suddenly was not enough anymore to
protect his privacy.

> all security out of protocols.

That's not I'm saying either. I'm saying that making it mandatory will not
improve the sites which already use it and will not improve the sites which
deliberately don't want to use it. It will just increase the breach between
the two categories and will even more confuse the end user.

I understand the benefit of using it for NPN, but that's the only real value.

> done!  Don't be so pessimistic as to say "aw, shucks, we can't do it"  - I

I'm not pessimistic, I'm basing my judgement on what has been done since
the beginning. Why do you think that people who deliberately don't care
about renewing their certs will suddenly change ? I'm facing cert alerts
every day during random browsing. You can be sure it will soon become worse
if we force users with even less consideration to produce a cert. We'll be
seeing self-signed certs everywhere with a life up to 2038.

> Let's vote in favor of the users, and fix the problem.

I'm one of the users and I want the situation to improve, not to become
worse. Right now the situation is already bad where TLS is used when not
needed. And it's bad where TLS is needed because there are many other
ways to get the info that is protected only by the transport.

> Protocols can and

Mike, as we discussed a few months ago, I would much more support your
proposals of using HTTP over a secured UDP. Really. It would provide
exactly the same model as TLS today (one which I'm not satisfied with)
but with much improved performance and lower deployment cost. But here
we're discussing about making it worse for end users and worse for server
admins. That's what I don't like in this model.

> straight into their sessions and accessing all their info.  Steal the

Many sites are already sensible to cookie injection and this is something
TLS cannot fix. Cookie hijacking has been in used by malware for years, I
have proofs of that in many server-side logs where the same session is
used in parallel in two countries with completely different browsing
behaviours.

Sometimes I'm scared because I fell like people who want to push TLS hard
really are not aware of the state of the browsing security in 2012, and
*this* is even more concerning to me than the overhead of processing TLS!

Willy

---

From: Mike Belshe <[email-masked]>
Date: Wed, 18 Jul 2012 00:50:35 -0700

> and injecting operations. Where is there any privacy in this model ?

They're still using TLS for a reason. These broad-stroke statements that
banks consider TLS worthless are simply false.  We can ask any bank about
it if you want.

I am not saying that there aren't security concerns about TLS - but TLS has
served us well for a long time and will continue to do so.  It will be
updated to be better.

> that his "https://" in front of the URL suddenly was not enough anymore to

Again, you're arguing that because there was a security breach once, we
should take all the locks off the doors.  This is silly!

> the two categories and will even more confuse the end user.

Yes it does.  Neither users nor administrators understand security well
enough.  People forget, they don't know what the padlock means, all sorts
of things.

We can take away this confusion by making it 100% secure all the time.

> seeing self-signed certs everywhere with a life up to 2038.

I don't get these every day.

But if this is a real problem, it will force us to fix the problem and make
it better.  We can innovate here.

> ways to get the info that is protected only by the transport.

This is like saying "I'll install the airbags when I need them".

> admins. That's what I don't like in this model.

There is no data that suggests it is worse for end users.   With Google,
Twitter, Facebook, every bank in the US all on TLS, its really quite
remarkable that you think that "TLS makes it worse for the end user".

The sites which aren't willing to spend the time to keep their users secure
probably shouldn't be operating.  Hosting sites like amazon, wordpress,
google, and microsoft will take care of the certificate management for all
sites.  The problems you describe of perpetually expired certs is overly
pessimistic.

> used in parallel in two countries with completely different browsing

Ah!  TLS makes it almost impossible to steal the cookie.  That's where TLS
kicks in.   As you know, you need many things to keep a system secure; TLS
is just one of them.  But its a vital part!  Without it, you're not a
secure system.

> *this* is even more concerning to me than the overhead of processing TLS!

Lets not get personal.

It does not go without notice from me that the battle lines are drawn
around which type of developer you are.  Browser developers and social
content providers are all in the protect-the-users camp (encrypt
everything).  Proxy vendors, which have an uncertain role in an encrypted
future, are unilaterally against it.  This is a power struggle of products.
 Are the endpoints in charge?  Or is the 3rd party middleman in charge?

Again, I vote for the user.

Mike

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Jul 2012 10:04:09 +0200

On 2012-07-18 09:50, Mike Belshe wrote:
> ...
> everything).  Proxy vendors, which have an uncertain role in an
> encrypted future, are unilaterally against it.  This is a power struggle
> of products.  Are the endpoints in charge?  Or is the 3rd party
> middleman in charge?
>
> ...

The user wants security. But the user also wants speed, or the ability 
to access a site from an environment that insists on opening the connection.

Best regards, Julian

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 08:09:28 +0000

------ Original Message ------
>On Wed, Jul 18, 2012 at 12:27 AM, Willy Tarreau <[email-masked]> wrote:

  And when a number of webmail accounts were recently suspected of 
  having been
  broken after a CA cert break-in, there was no way for the poor user 
  to suspect
  that his "https://" in front of the URL suddenly was not enough 
  anymore to
  protect his privacy.
 
 Again, you're arguing that because there was a security breach once, 
 we should take all the locks off the doors.  This is silly!

that would be silly, but no-one is arguing that.

We're arguing against being compelled to put a lock on every door... 
even internal doors.

We're arguing against having our freedom removed to choose which doors 
to put our lock on.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 18 Jul 2012 10:11:22 +0200

> banks consider TLS worthless are simply false.  We can ask any bank about

I work for one and I can assure you that everyone there says that they're
designing the security model as if communications were clear text (and
they are with regards to the malware ennemy). Certs are marketing only
(show a green cert and reassure your customers).

> served us well for a long time and will continue to do so.  It will be

TLS is fine for a very large number of uses and it's already been used where
it's fine. Let's not make it globally worse by forcing incompetent admins to
adopt it without understanding it, which results in end users having to deal
with errors and warnings all the day.

> should take all the locks off the doors.  This is silly!

No, I'm not saying this at all. I'm saying that we don't need to put locks
on all doors just because one was broken. It's very different. I'm not
advocating for removing TLS, but for keeping it as it is today : used by
those who need or care about it.

It's the same with locks : if you force everyone to add a new lock to their
door, some lock makers will sell many poor quality locks with the same key
reused multiple times and the overall security will be worse because some
people will buy these locks when they need security without knowing how
bad they are.

> > I'm saying that making it mandatory will not

Please, don't confuse 100% secure with "always encrypted". It's really not
the same, and I'm claiming that "always encrypted even when not needed"
will lower the % of secure deployments.

> I don't get these every day.

Maybe you're just using a small subset of the web then, I don't know. Or
maybe your browser hides the warning for you already ?

> it better.  We can innovate here.

I'd rather fix real issues than fixing problems we'll create on purpose.

> remarkable that you think that "TLS makes it worse for the end user".

TLS on such well-managed sites is not worse (except the extra round trip
which is why I never use TLS on Google, as it increases its load time).

TLS on *every* site is worse.

> probably shouldn't be operating.

So we're back to the web-for-the-elite. If you have $100K to spend a year on
an admin to maintain your certs, you're allowed to be connected, otherwise
go away. At least things get clearer now.

> Hosting sites like amazon, wordpress,

It's not overly pessimistic, I'm getting them right now while TLS is on a
minority of web sites. When it's 100% of web sites, I'm sure we'll have
browser plugins to automatically validate sites for you !

> Ah!  TLS makes it almost impossible to steal the cookie.

On the wire. Reread what I wrote above. Cookie is stolen in the browser
nowadays, it's easier and you don't need to be connected between the
browser and the server, you just have to stuff your code in every
browser. Much easier and no risk of being caught !

> That's where TLS

It's not a vital part but an additional part. Once again, I'm working
with people who consider that communications are cleartext nowadays. We're
working with ways to secure a browsing sequence when someone else has the
same cookie and browses in parallel. That's not science fiction, that's
todays web and it's been like this for at least the last 5 years.

> > *this* is even more concerning to me than the overhead of processing TLS!

You're right, sorry.

>  Are the endpoints in charge?  Or is the 3rd party middleman in charge?

I have a different analysis. We're discussing something which is defined
by a minority of web sites who own the majority of the traffic, man power
and even CPU power in the world. It's absolutely normal that protocols
designed in such environments totally forget what a *normal* site looks
like. And it's totally normal that they don't understand why it's hard
to get things to work right at many places.

The 3rd party middleman you're talking about are more commonly in contact
with such real world sites and possibly are more sensible to their concerns
and issues.

> Again, I vote for the user.

I'm for the user too, I just think the model you see for the future user
is a major failure which users will regret because of the increased
issues they will have to deal with without understanding.

Regards,
Willy

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Wed, 18 Jul 2012 08:26:14 +0000

Mike,

I think the reason why your argument fails to convince is that it is made at the wrong layer. It is essentially not an HTTP issue but a content provider issue whether content is exposed over TLS or not. Every content provider today has the option of using TLS or not -- some has chosen to use it and others not. It would be much more beneficial if you could convince content providers that is it a good idea for them to use TLS.

I think you would feel the same if I argued that TCP should be abandoned in favor or TLS throughout the Internet. Clearly that would feel like overreach from a policy point of view that doesn't reflect what TCP is actually used for. 

I doubt you will find anybody who will "vote against the user" but it also somewhat naïve to say that the user is "safe" if we use TLS. There are so many other aspects (privacy, tracking, etc.) that directly involve content providers directly so rather than focusing on one particular aspect (TLS) I would argue that the right discussion to have is with content providers about what it means to expose data in a safe manner. Not whether TLS should be mandatory in HTTP or not.

Henrik

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Wednesday, July 18, 2012 1:04 AM
To: Mike Belshe
Cc: Willy Tarreau; Phillip Hallam-Baker; Adrien W. de Croy; Rajeev Bector; Martin Thomson; "Martin J. Dürst"; Doug Beaver; [email-masked]
Subject: Re: HTTP2 Expression of Interest

On 2012-07-18 09:50, Mike Belshe wrote:
> encrypted future, are unilaterally against it.  This is a power 
> struggle of products.  Are the endpoints in charge?  Or is the 3rd 
> party middleman in charge?
>

The user wants security. But the user also wants speed, or the ability to access a site from an environment that insists on opening the connection.

Best regards, Julian

---

From: Mike Belshe <[email-masked]>
Date: Wed, 18 Jul 2012 01:48:17 -0700

On Wed, Jul 18, 2012 at 1:26 AM, Henrik Frystyk Nielsen <
[email-masked]> wrote:

> Mike,
>
> I think the reason why your argument fails to convince is that it is made
> at the wrong layer.

I don't think it fails to convince.  I'm winning this argument by a mile!
 I'd be happy to take a poll to find out.

mike

> It is essentially not an HTTP issue but a content provider issue whether
> content is exposed over TLS or not. Every content provider today has the
> option of using TLS or not -- some has chosen to use it and others not. It
> would be much more beneficial if you could convince content providers that
> is it a good idea for them to use TLS.

> I think you would feel the same if I argued that TCP should be abandoned
> in favor or TLS throughout the Internet. Clearly that would feel like
> overreach from a policy point of view that doesn't reflect what TCP is
> actually used for.
>
> I doubt you will find anybody who will "vote against the user" but it also
> somewhat naïve to say that the user is "safe" if we use TLS.

Having TLS does not make you safe.  But not having it *does* make you
unsafe.

Mike

> There are so many other aspects (privacy, tracking, etc.) that directly
> involve content providers directly so rather than focusing on one
> particular aspect (TLS) I would argue that the right discussion to have is
> with content providers about what it means to expose data in a safe manner.
> Not whether TLS should be mandatory in HTTP or not.
>
> Henrik
>
> Cc: Willy Tarreau; Phillip Hallam-Baker; Adrien W. de Croy; Rajeev Bector;
> Martin Thomson; "Martin J. Dürst"; Doug Beaver; [email-masked]
> The user wants security. But the user also wants speed, or the ability to
> access a site from an environment that insists on opening the connection.
>
> Best regards, Julian
>
>
>
>
>
>
>

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 08:51:26 +0000

I think also it's not always clear who the user is.  It's certainly 
naive to think they all want / need / deserve the same thing.

We get paid by customers.

We don't in general get paid by users.

Users are in our case typically employees or students.  They don't get 
to make the rules about what they can do in company time.  Nor should 
they.

Adrien

------ Original Message ------
From: "Henrik Frystyk Nielsen" <[email-masked]>
To: "Julian Reschke" <[email-masked]>;"Mike Belshe" 
<[email-masked]>
Cc: "Willy Tarreau" <[email-masked]>;"Phillip Hallam-Baker" 
<[email-masked]>;"Adrien W. de Croy" <[email-masked]>;"Rajeev 
Bector" <[email-masked]>;"Martin Thomson" 
<[email-masked]>;"Martin J. Dürst" 
<[email-masked]>;"Doug Beaver" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 18/07/2012 8:26:14 p.m.
Subject: RE: HTTP2 Expression of Interest

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 18 Jul 2012 08:52:51 +0000

------ Original Message ------
>
>
>On Wed, Jul 18, 2012 at 1:26 AM, Henrik Frystyk Nielsen <[email-masked]> wrote:
> Mike,
> 
> I think the reason why your argument fails to convince is that it is 
> made at the wrong layer. 
 
 I don't think it fails to convince.  I'm winning this argument by a 
 mile!  I'd be happy to take a poll to find out.

It must be getting very late there Mike, we appreciate your engagement 
in the issue, but I don't think it's accurate to claim you're even 
ahead in the argument.

Adrien

> It is essentially not an HTTP issue but a content provider issue 
> whether content is exposed over TLS or not. Every content provider 
> today has the option of using TLS or not -- some has chosen to use it 
> and others not. It would be much more beneficial if you could 
> convince content providers that is it a good idea for them to use 
> TLS. 
  
  I think you would feel the same if I argued that TCP should be 
  abandoned in favor or TLS throughout the Internet. Clearly that would 
  feel like overreach from a policy point of view that doesn't reflect 
  what TCP is actually used for.
  
  I doubt you will find anybody who will "vote against the user" but it 
  also somewhat naïve to say that the user is "safe" if we use TLS. 

 Mike

  There are so many other aspects (privacy, tracking, etc.) that 
  directly involve content providers directly so rather than focusing 
  on one particular aspect (TLS) I would argue that the right 
  discussion to have is with content providers about what it means to 
  expose data in a safe manner. Not whether TLS should be mandatory in 
  HTTP or not.
  
  Henrik
  
  -----Original Message-----
  From: Julian Reschke [mailto:[email-masked]]
  Sent: Wednesday, July 18, 2012 1:04 AM
  To: Mike Belshe
  Cc: Willy Tarreau; Phillip Hallam-Baker; Adrien W. de Croy; Rajeev 
  Bector; Martin Thomson; "Martin J. Dürst"; Doug Beaver; [email-masked]
  Subject: Re: HTTP2 Expression of Interest
  
  > Again, I vote for the user.
  
  The user wants security. But the user also wants speed, or the 
  ability to access a site from an environment that insists on opening 
  the connection.
  
  Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 18 Jul 2012 08:53:44 +0000

In message <CABaLYCtx_PNFrTxkbjgnKpuGX=[email-masked]>

Mike,

Nobody is proposing to take TLS away from you.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 18 Jul 2012 08:16:18 -0400

On Wed, Jul 18, 2012 at 1:13 AM, Mike Belshe <[email-masked]> wrote:
> on a lightbulb?  I could just use UDP!"  I suggest we design for the future,
> not the past.

Mandating bloat is not designing for the future. I am talking about
the present. I HAVE a light bulb (actually a board with LEDs mounted)
that has a Web server embedded.

One of the design requirements of a lightbulb is instant-on.

> It's all negotiated in the handshake.  You'll know who is TLS and who is

Not without knowledge of the security policy. Without that you are
subject to a downgrade attack.

> example.  I know you're aware of Firesheep.  We should make it impossible to
> use firesheep in 2020.  Right?

I would much prefer to get rid of password based authentication which
is the driving use case for most use of SSL.