Subject: editorial feedback on draft-mbelshe-httpbis-spdy-00

From: Julian Reschke <[email-masked]>
Date: Sat, 24 Mar 2012 15:00:14 +0100

1. Overview

I find the statement about pipelining a bit ... unbalanced. 
"Intermediary Inference" is no problem at all if you run over SSL, which 
is something SPDY does by default. Unless I'm missing something.

3.2.1 Request

":version" - so this essentially positions SPDY as alternate transport 
layer for HTTP; preserving the version number. Out of curiosity; what is 
it needed for? Preserving all information when tunneling? The same 
question applies to ":scheme"...

3.2.3 Authentication

a) as far as I understand, RFC 4559 does not define the "NTLM" scheme.

b) in general, it's not clear why this paragraph is here; does 
Authentication work any different than in HTTP? Maybe just point to 
HTTPbis P7?

3.3

"Browsers MUST implement throttles..."

That doesn't seem to be testable. Maybe replace with advice in prose.

6.2 SETTINGS frame

This seems to be a feature complete orthogonal to the remainder of the 
spec. Maybe just remove it?

Editorial Nits:

Boilerplate: month name needs to be a full name, such as "February"

Abstract: should not contain references (so just remove the "[RFC2616]")

(speaking of which this should really reference HTTPbis)

Terminology: "header" -> "header field"

2.2.1 Control Frames

has "...see Control Frames for the complete list..."; this should be a 
proper reference (to where?)

2.2.2 Data frames

s/MUST send issue/MUST issue/

3.2.1

Cites RFC 1738 for URI syntax; should cite RFC 3986.

3.3

Example host names should use the names reserved for this purpose.

s/disc cache/cache/

10.

The TLSNPN reference needs to use the proper reference format for 
Internet Drafts. I also note that the referenced spec has expired a few 
months ago; if this is an integral part of SPDY we need to figure out 
how to make progress on it.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Sat, 24 Mar 2012 09:19:14 -0700

On Sat, Mar 24, 2012 at 7:00 AM, Julian Reschke <[email-masked]>wrote:

> 1. Overview
>
> I find the statement about pipelining a bit ... unbalanced. "Intermediary
> Inference" is no problem at all if you run over SSL, which is something
> SPDY does by default. Unless I'm missing something.

Agreed.

> layer for HTTP; preserving the version number. Out of curiosity; what is it
> needed for? Preserving all information when tunneling? The same question
> applies to ":scheme"...
>

Since it's possible to layer different (future) versions of HTTP on top of
SPDY, don't we need the ":version" header to preserve all information? And
similarly, we can conceivably handle different schemes over SPDY, such as
https (the obvious one), http, ws, wss, etc, so I think including ":scheme"
is important.

> Authentication work any different than in HTTP? Maybe just point to HTTPbis
> P7?
>
>
> 3.3
>

Are you saying you don't feel it's worthwhile calling out the privacy
consideration of SETTINGS frames? I'm unclear what you mean by being
orthogonal to the remainder of the spec.

> Editorial Nits:

Thanks. Updated some of them at
https://github.com/mbelshe/SPDY-Specification/commit/e940e5d3c1cc930e52bd30b7e03f78573c0e04ad
.

> Boilerplate: month name needs to be a full name, such as "February"

Done

> Abstract: should not contain references (so just remove the "[RFC2616]")

Done

> Terminology: "header" -> "header field"

Where?

> proper reference (to where?)

Not done yet.

> s/MUST send issue/MUST issue/

Done

> Cites RFC 1738 for URI syntax; should cite RFC 3986.

Done

> Example host names should use the names reserved for this purpose.

Which ones are those?

> s/disc cache/cache/

I assume you meant s/disk cache/cache/. Done.

>
> 10.
>
> The TLSNPN reference needs to use the proper reference format for Internet
> Drafts. I also note that the referenced spec has expired a few months ago;
> if this is an integral part of SPDY we need to figure out how to make
> progress on it.
>

Agreed. It languished for awhile, but I think we need to revive the TLSNPN
discussions.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Mar 2012 01:19:21 +0100

On 2012-03-24 17:19, William Chan (陈智昌) wrote:
> ...
>     3.2.1 Request
>
>     ":version" - so this essentially positions SPDY as alternate
>     transport layer for HTTP; preserving the version number. Out of
>     curiosity; what is it needed for? Preserving all information when
>     tunneling? The same question applies to ":scheme"...
>
>
> Since it's possible to layer different (future) versions of HTTP on top
> of SPDY, don't we need the ":version" header to preserve all
> information? And similarly, we can conceivably handle different schemes
> over SPDY, such as https (the obvious one), http, ws, wss, etc, so I
> think including ":scheme" is important.

If we see SPDY as a transport layer only yes; if we consider it 
HTTP/2.0; maybe not.

(This applies to http and https; ws and wss are simply different 
protocol you can switch http to).

>     6.2 SETTINGS frame
>
>     This seems to be a feature complete orthogonal to the remainder of
>     the spec. Maybe just remove it?
>
>

Sorry, wrong spec section. I was wondering whether the SETTINGS frame is 
needed at all.

> https://github.com/mbelshe/SPDY-Specification/commit/e940e5d3c1cc930e52bd30b7e03f78573c0e04ad.
>
>

Will have to check...

>
>     has "...see Control Frames for the complete list..."; this should be
>     a proper reference (to where?)
>
>
> Not done yet.
>
>
>     2.2.2 Data frames
>

*.example.com and *.example.org for instance; there's an RFC about that, 
but I'm too lazy to look it up right now :-)

> I assume you meant s/disk cache/cache/. Done.

Yes.

>     Internet Drafts. I also note that the referenced spec has expired a
>     few months ago; if this is an integral part of SPDY we need to
>     figure out how to make progress on it.
>
>
> Agreed. It languished for awhile, but I think we need to revive the
> TLSNPN discussions.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Mar 2012 00:49:36 +0100

Will have to check...

Yes.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 10:59:27 +0000

>If we see SPDY as a transport layer only yes; if we consider it 

Ok, can we just settle this once and for all ?

Given:

	1. HTTP/1.1 already has two different widely used transport
	   protocols: HTTP and HTTPS

	2. SPDY's requirement for SSL is never going to fly with
	   p0rn^Wmultimedia sites, national emergency services,
	   and other high volume/high spike sites.

	3. There is significant interest in HTTP over UDP in certain
	   markets.

	4. There are already a number of HTTP over FOO definitions,
	   for various values of FOO.

	5. Any realistic HTTP/2.0 implementation will be multiprotocol
	   anyway, because it will also have to support HTTP/1.1
	   and probably HTTPS, in addition to whatever HTTP/2.0
	   brings.

Why do some people still consider it a workable idea to just goldplate
SPDY as HTTP/2.0 ?

Isn't the idea to make HTTP/2.0 more desirable than HTTP/1.1 ?

If we don't make it more desirable for the majority of the web,
people will vote with their packets, and HTTP/1.1 will continue to
be the default protocol.  (See also: IPv6)

I propose that we decide, once and for all, that HTTP/2.0, unlike
HTTP/1.1, SHALL be standardized with the expectation and support for
multiple transport protocols, right from the beginning.

And of course HTTP/2.0 should come with a "canonical" TCP based
transport protocol, and of course somebody will push for that being
SPDY.

But such a decision on our part will seem a lot less moronic if
HTTP/2.0 can work with alternative transports.

-- 
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: Peter Saint-Andre <[email-masked]>
Date: Sun, 25 Mar 2012 13:20:21 +0200

<hat type='AD'/>

> Ok, can we just settle this once and for all ?

That's the point of the recent recharter to the HTTPBIS WG:

https://datatracker.ietf.org/wg/httpbis/charter/

Specifically, if people have proposals, encourage them to write
Internet-Drafts. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 11:33:51 +0000

>Specifically, if people have proposals, encourage them to write

I think we have a disconnect here Peter.

The charter does not make it clear if HTTP/2.0 will be single or
multiple protocol and that decision should be made before people
start spending serious time on proposals.

If it is multiprotocol, there is a "market" for special purpose
transport protocols, such as HTTP over UDP.

If it is single protocol, there is only a market for a single
protocol, general enough to satisfy the widest possible range of
users.

We need to give people that guidance, so they know what they
are writing a protocol for.

So what is it ?  single or multi ?

---

From: Barry Leiba <[email-masked]>
Date: Sun, 25 Mar 2012 14:04:53 +0200

>           protocols: HTTP and HTTPS

HTTP and HTTPS are NOT transport protocols.  TCP is the transport protocol
that HTTP usually uses (compare with UDP and SCTP).  HTTPS also uses TCP,
with TLS on the half-layer in between.

It's important to keep that in mind, so we don't confuse ourselves when we
talk about UDP, for instance.  SPDY affects TCP.  Whether we consider SPDY
to be a transport protocol on its own, a transport-layer modification of
TCP, or, like TLS, something we refer to as "transport layer" but that's
actually sitting on a half-layer in between, is then a matter of discussion
and understanding.

And as PSA said, this is all for the HTTP 2.0 discussion to have, along
with I-Ds to use as discussion points.

Barry, incoming AD

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 12:14:14 +0000

In message <CAC4RtVDOR-hxYOwrRD6nt6tB9nkAfR=[email-masked]>
, Barry Leiba writes:

>HTTP and HTTPS are NOT transport protocols.

For all I care, you can call them "transport", "session" or even
"presentation" protocols if that makes you feel better.

But this semantic outrage does not answer my very simple
question: Will HTTP/2.0 support only one or will it support
multiple protocols ?

>with I-Ds to use as discussion points.

And just why should people spend time on I-D's, when it for all
intents and purposes looks like httpbis is now chartered to goldplate
SPDY as HTTP/2.0 ?

If you really want I-D's to discuss, the very least you could do is
to make it clear to people that they are not wasting their time writing
them.

As long as this "Ohh nothing has been decided yet, but look at that
SPDY, ain't it shiny ?" charade is going on, nobody in a sane state
of mind is going to waste their time on an I-D with no future.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Mar 2012 14:22:01 +0200

On 2012-03-25 14:14, Poul-Henning Kamp wrote:
> In message<CAC4RtVDOR-hxYOwrRD6nt6tB9nkAfR=[email-masked]>
> , Barry Leiba writes:
>

I believe the answer is: we don't know yet.

> intents and purposes looks like httpbis is now chartered to goldplate

It's not, and if a line in my SPDY feedback upset you, I apologize.

I believe that SPDY contains good parts that are already tested, and we 
should learn from them. But there are lots of other things we may want 
to fix/change in HTTP/2.0, and which SPDY doesn't address at all.

I also believe that it's good to have a proper spec for SPDY, no matter 
whether it becomes part of a future HTTP spec or not.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 12:39:17 +0000

>I believe the answer is: we don't know yet.

So shouldn't we find out, so that people know what they are
aiming for with their I-D's ?

I personally have a hard time seeing how we can ever bend the world
to come to a conclusion that HTTP/2.0 will be single-protocol, given
the HTTP/1.1 interop issue, but I am willing to be educated, if
somebody has good arguments for that position.

On the other hand, if nobody is going to argue for that HTTP/2.0
should be single-protocol, then multi-protocol seems like a foregone
conclusion, which we should minute and take into account.

>It's not, and if a line in my SPDY feedback upset you, I apologize.

Not at all, it was just yet another instance of pussyfooting around
this question, rather than get the answer nailed down so we know
what we're trying to build here.

>I believe that SPDY contains good parts [...]

I agree, SPDY has some very desirable features for certain use-cases,
and I would hate to see a HTTP/2.0 that didn't allow for something
like SPDY to be used.

>whether it becomes part of a future HTTP spec or not.

Again, I agree, and I belive that it would be easier to do a good
job, if you know if SPDY will be THE protocol or just A protocol.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 25 Mar 2012 15:02:31 +0200

> aiming for with their I-D's ?

If you have requirements and arguments to back them up, please put them into a form that's helpful (e.g., an I-D, or just more detail on-list if need be). The point of the process is to have this discussion, not to "gold-plate" anything.

> somebody has good arguments for that position.

What do you want from "multi-protocol" -- is it "protocol independence"? I.e., the ability to swap one for the other without anyone noticing?

Cheers,

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

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Mar 2012 15:50:47 +0200

> Specifically, if people have proposals, encourage them to write

Amos and I are currently working on such a proposal. Poul-Henning,
feel free to join if you'd like.

Cheers,
Willy

---

From: tom <[email-masked]>
Date: Sun, 25 Mar 2012 22:05:08 +0800

To carry HTTP over UDP is what we are studying on. the goa is to setup P2P
topology within browsers for next web.

HTTP need a underhood reliable transport like TCP/SCTP. Run HTTP over the
multiple reliable transport should be reasonable.

Best regards
  Tom

On Sun, Mar 25, 2012 at 9:02 PM, Mark Nottingham <[email-masked]> wrote:

> If you have requirements and arguments to back them up, please put them
> into a form that's helpful (e.g., an I-D, or just more detail on-list if
> need be). The point of the process is to have this discussion, not to
> "gold-plate" anything.
>
>
> What do you want from "multi-protocol" -- is it "protocol independence"?
> I.e., the ability to swap one for the other without anyone noticing?
>
> Cheers,
>
> --
> Mark Nottingham
> http://www.mnot.net/
>
>
>
>
>
>

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 14:18:17 +0000

In message <[email-masked]>, Mark Nottingham wri

>What do you want from "multi-protocol" -- is it "protocol independence"?

No, it is software quality, and solution performance.

With respect to software quality, there should be no need to read all
333 pages of HTTPbis output, just to find out what it takes to move
a message across the wire.

Having "transport message definition" separated from "message
semantics interpretation" means that designing and debugging both
sides of that (virtual) API becomes much easier.

The HTTPbis effort have made it easier to spot the line where it
exists, but it is still hidden in old dirty hacks a lot of places.

Even if we end up with only one protocol defined, having the interface
between transport and semantics clearly defined will make that job easier.

As for performance, Varnish has users who are starting to knock on
the underside of one million requests a second per machine, at these
levels of trafic, neither SSL nor CRNL terminated text formats play
well with the SOCKET-API for pulling stuff out of TCP connections.

Just to give an idea about the kind of numbers we are talking about,
I think HTTP/2.0 should have a performance goal for one of its
transports, that a COTS machine can run a (load-balancer) at
wire-speed for 500.000 clients, with less than 5% CPU usage.  Given
that we'll take a couple of years, this may be too unambitious.

So, what I would really like to see come out of HTTPbis is four
standards, (each of which might be one or more documents):

	HTTP/2.0 semantics:
		Defines what HTTP/2.0 messages mean. 

		(Ie: GET, POST, Vary, E-tags, Sessions, Cookies...)

	HTTP/2.0 transport requirements:
		Defines the message components and the primitives a
		transport protocol must/can support.

		(Ie: http_req is {req,proto,metadata*,data+}, endpoint
		identification/X-F-F etc.)

	HTTP/2.0 high performance bulk transport
		Transport for moving lots of bits fast.

		(Ie: HTTP/1.1 with length-prefixes and maybe metadata
		enumeration/compression. No-RTT penalty HTTP/1.1
		upgrade by sending first request as HTTP/1.1 with
		"I can do HTTP/2.0" marker.  Maybe pipelining/mux
		to fill windows) 

	HTTP/2.0 full feature transport
		Transports for fancy HTTP apps which needs server
		push, websockets, mux, pipeline, crypto (Ident,
		Auth, Priv, Integ, non-repudiation etc.)

		(Ie: Probably something like a fuller marriage of
		SPDY and HTTPS, switching to this protocol with
		"UPGRADE" is probably perfectly acceptable.)

And this is why I think that the second document is much more
important to focus on right now, than specifying SPDY without having
specified where ind what it plugs into.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Mar 2012 16:24:30 +0200

On 2012-03-25 16:18, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Mark Nottingham wri
> tes:
>

It should be sufficient to read the ~70 pages of Part1 which are not 
boilerplate/toc/changelogs/index.

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Sun, 25 Mar 2012 14:29:17 +0000

>boilerplate/toc/changelogs/index.

Last I looked it was not.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 25 Mar 2012 16:44:30 +0200

On 2012-03-25 16:29, Poul-Henning Kamp wrote:
> In message<[email-masked]>, Julian Reschke writes:

Details, please :-)

---

From: Brian Pane <[email-masked]>
Date: Sun, 25 Mar 2012 17:50:39 -0700

>           and other high volume/high spike sites.

It looks like the current SPDY proposal only requires TCP, not SSL:
http://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00#section-2

Nonetheless, I think it would be reasonable for HTTP/2.0 to require SSL.

When HTTP/0.9 was first deployed, the typical client environment was
an academic LAN where the users trusted each other.  Today, the
typical client environment is a coffee shop with an open wireless
network.

If HTTP/2.0 has an operational life as long as HTTP/1.x has had,
decisions made this year will determine the default security of the
web in 2028.

If the HTTP/2.0 standard mandates TLS, it will create pressure for
implementors in the short term.  But that's good, because implementors
will see it as an opportunity.  Hardware developers will step up their
efforts to accelerate common ciphersuites.  Software developers will
step up their efforts to make session resumption scale.  And the
per-byte and per-session cost will drop.  And all those people in the
coffee shop will be better protected.

-Brian

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 00:55:31 +0000

wrt proxies and TLS... 
  
making TLS hop by hop rather than end to end would make life a lot 
easier, and still provide protection for coffee shop users, proxy 
access to payload, while not mandating the CPU burden in trusted 
environments (e.g. reverse proxy).
  
Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 05:56:53 +0000

>Nonetheless, I think it would be reasonable for HTTP/2.0 to require SSL.

I think you need to talk to some people with big websites ;-)

There are a large swath of the HTTP traffic that doesn't need and cannot
afford the overhead of crypto and if you mandate that HTTP/2.0 use
crypto, they will simply stay on HTTP/1.1 forever.

If we act sensibly and make room for multiple transports, it is a non
issue, because then you can have one transport with and one without
crypto.

Which is amazingly just like the situation today:  The servers which care
about ident/auth/integ/priv/... run HTTPS, everybody else runs HTTP.

---

From: Brian Pane <[email-masked]>
Date: Mon, 26 Mar 2012 00:16:20 -0700

> I think you need to talk to some people with big websites ;-)

In my day job, I work on L7 performance at a website with
800 million users. Does that count? ;-)

> crypto, they will simply stay on HTTP/1.1 forever.

The cost of the crypto overhead isn't what it used to be.
Nowadays a single core of a commodity CPU can do
thousands of 1024-bit RSA operations per second or
well over a Gb/s of RC4 or AES encryption.

-Brian

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 26 Mar 2012 09:44:04 +0200

On 3/26/2012 7:56 AM, Poul-Henning Kamp wrote:
> In message<CAAbTgTu7qbPiREWRRqFddgoko0FCt0jmxR=[email-masked]>
> , Brian Pane writes:
>
Existence proofs: google does all of their logged in user search over 
SSL, Twitter encourages SSL by default, Facebook is widely used that 
way. It pretty clearly can be done at scale. Its not free, but its worth it.

More importantly - no user wants to use an insecure protocol - ever. Web 
protocol design should serve them first. They have an unmet expectation 
of privacy and security that we should meet by making the application 
protocol secure all the time; the mixed- content vulnerabilities of 
HTTP/1 make that clear to me.

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 08:06:00 +0000

>800 million users. Does that count? ;-)

Appearantly not ?

>well over a Gb/s of RC4 or AES encryption.

But what if people had other plans for their CPU cycles ?

A lot of people just want their content delivered cheaply and fastly,
and if you try to push SSL on them, they'll not use your protocol.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Mar 2012 10:10:03 +0200

On Mar 26, 2012, at 9:44 AM, patrick mcmanus wrote:

> Existence proofs: google does all of their logged in user search over SSL, Twitter encourages SSL by default, Facebook is widely used that way. It pretty clearly can be done at scale. Its not free, but its worth it.
> 
> More importantly - no user wants to use an insecure protocol - ever. Web protocol design should serve them first. They have an unmet expectation of privacy and security that we should meet by making the application protocol secure all the time; the mixed- content vulnerabilities of HTTP/1 make that clear to me.

I've never considered SSL to be a means of securing the protocol.
It does a decent job of hiding the exchange of data from passive
observers, but the way that typical user agents handle certificate
management lacks what I would consider a secure protocol.

In any case, the notion that every user wants a secure protocol is
irrelevant.  There are many examples of HTTP use, in practice, for
which SSL/TLS is neither desired nor appropriate.  Even simple things,
like the exchange that Apple devices use to discover network access point
logins, cannot work with an assumption of SSL/TLS.  Likewise, many uses of
HTTP are in kiosks, public schools, libraries, and other areas for which
your concern as a user is less important than the organization's
responsibility to prevent misuse.

There are ways to have both a secure protocol and visibility for
intermediaries, but we don't have to agree to any of these "requirements"
up front.  If the protocol proposals can't stand for themselves, then
I have no need for a new protocol.

....Roy

---

From: Mike Belshe <[email-masked]>
Date: Mon, 26 Mar 2012 10:21:03 +0200

> I think you need to talk to some people with big websites ;-)

We're at a crossroads here, which comes down to goals.

One one hand, we have the opportunity to help users have secure access to
the web, always.

On the other hand, we can continue to allow websites to be unsecured,
creating privacy and security risks for users.

I challenge you to find a single user on the web that wants an unsecured
Internet.  I don't think these users exist. Everyone wants privacy and
security; and most users don't realize they don't have it.  I know there
are websites which want to minimize their capital expenditure costs, even
if it puts their users at risk.  We could cater to the websites - or we
could cater to the users.

Which is more forward looking?  Which road do you want to take?

In all other products, security is not an option.  It's a requirement.
Users expect it and users need it.  How can anyone seriously argue to not
even try in our protocols?  If not now, when would you argue to start
trying?  Never?

Two last things.

First, whatever we define today takes years to deploy.  CPU costs continue
to go down at a remarkable rate.  Moore's law over the last decade has
definitely made SSL viable on cheap hardware like never before.   We should
be designing for going forward - where CPU costs continue to shrink.  If a
website is willing to put its users at risk (which is downright
irresponsible if you ask me), let them use HTTP/1.1.  The future should be
secure.

Second, SSL will remain substandard on performance until we make it a
requirement.  Its a self-fulfilling prophecy that SSL implementations are
slow as long as we don't try to take them seriously.

Mike

PS - if you don't believe me about the importance of security, look to all
the major content providers for social activity today.  Google and Twitter
are already 100% SSL.  Facebook and Microsoft are not far behind.  Users
need security and they need it now.  We should stop talking about it as
though its optional.

A better argument would be "is SSL the right way to secure the web?", and
 not,  "should we secure the web?".

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 08:34:22 +0000

>way. It pretty clearly can be done at scale. Its not free, but its worth it.

The fact that a certain size and class of companies roll out SSL is
no where near a proof that everybody would or should do so.

Counter proof: How many p0rn sites deliver legal images via SSL ?

>More importantly - no user wants to use an insecure protocol - ever.

I don't think the majority of users consider HTTP an unsecure
protocol for p0rn, newspapers and blogs.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 26 Mar 2012 10:34:38 +0200

On Mon, Mar 26, 2012 at 10:10 AM, Roy T. Fielding <[email-masked]> wrote:

> SSL, Twitter encourages SSL by default, Facebook is widely used that way.
> It pretty clearly can be done at scale. Its not free, but its worth it.
> >
> protocol design should serve them first. They have an unmet expectation of
> privacy and security that we should meet by making the application protocol
> secure all the time; the mixed- content vulnerabilities of HTTP/1 make that
> clear to me.
>
>

There are two discussions here:
   a) should http be secured (and what "secured" means)
   b) whether SSL is the right choice

>From a practical point of view, there aren't a lot of alternatives to SSL
on the table right now.  Most people do agree that SSL does a reasonable
job of preventing eavesdropping.

> responsibility to prevent misuse.

I don't know of any examples where users want unsecured products or
protocols, actually.  We can't solve all security issues of course, but
that doesn't mean we should leave it wide open either.  And we can solve
much of the eavesdropping problem right now.  So the question is really -
why wouldn't we?

> I have no need for a new protocol.

Protocols will only succeed if they provide real value.  There is a
subjective question of whether security and privacy is part of the value or
not.

Mike

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 26 Mar 2012 10:49:20 +0200

On 3/26/2012 10:34 AM, Poul-Henning Kamp wrote:
> In message<[email-masked]>, patrick mcmanus writes:
> I don't think the majority of users consider HTTP an unsecure protocol 
> for p0rn, newspapers and blogs. 

I disagree strongly. What users read and view should be private at this 
level.

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 26 Mar 2012 10:55:38 +0200

Hi Roy,

> I've never considered SSL to be a means of securing the protocol.
I'm fine with another answer to security if there is a better one 
available. My expectation is that SSL will evolve to solve some of its 
shortcomings and that is a reasonable train to be linked on to.

> irrelevant.

I disagree. To me its fundamental and the checkered history of HTTP/1 in 
this space should inform the next revision.

>    There are many examples of HTTP use, in practice, for
> logins, cannot work with an assumption of SSL/TLS.

Can you explain the Apple use case in detail? That sounds interesting, 
although I don't have the presumption that this has to be the only 
protocol to satisfy every use case.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 08:56:30 +0000

------ Original Message ------
From: "Mike Belshe" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: "patrick mcmanus" <[email-masked]>;"[email-masked]" 
<[email-masked]>
Sent: 26/03/2012 9:34:38 p.m.
Subject: Re: SPDY = HTTP/2.0 or not ?
> > Existence proofs: google does all of their logged in user search 
> over SSL, Twitter encourages SSL by default, Facebook is widely used 
> that way. It pretty clearly can be done at scale. Its not free, but 
> its worth it.
> >
> > More importantly - no user wants to use an insecure protocol - 
> ever. Web protocol design should serve them first. They have an unmet 
> expectation of privacy and security that we should meet by making the 
> application protocol secure all the time; the mixed- content 
> vulnerabilities of HTTP/1 make that clear to me.
> 
> 
 
 There are two discussions here:
    a) should http be secured (and what "secured" means)
a-1.  Should it be mandatory or optional.
  
my vote: optional.  
  
>From a practical point of view, there aren't a lot of alternatives to 
>SSL on the table right now.  Most people do agree that SSL does a 
>reasonable job of preventing eavesdropping.
  
I can see a lot of resistance from customers told they now need to buy 
and maintain a certificate from a CA just to run a webserver.
  
Sure they can run a self-signed cert, but that doesn't fulfil the goal 
of giving the user security.
  
There are so many devices running an HTTP server now which don't have 
the option to put in a cert.  E.g. web admin on my ADSL modem.
  
It just makes no sense to say that it should be mandatory.
 
 I don't know of any examples where users want unsecured products or 
 protocols, actually.  We can't solve all security issues of course, 
 but that doesn't mean we should leave it wide open either.  And we can 
 solve much of the eavesdropping problem right now.  So the question is 
 really - why wouldn't we?
  
my biggest concern is the mandatory nature of SSL/TLS in the proposal.
  
We will get access to the payload.  
  
If it is allowed it in the protocol, we can do it well.
  
Otherwise we will do it badly.  Which do you prefer?  We _will_ do it.
  
Because customers insist we do.
  
Adrien
 
 Protocols will only succeed if they provide real value.  There is a 
 subjective question of whether security and privacy is part of the 
 value or not.
 
 Mike

  ....Roy

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 11:03:30 +0200

On 3/26/12 10:56 AM, Adrien W. de Croy wrote:

>> From a practical point of view, there aren't a lot of
>> alternatives to SSL on the table right now.  Most people do agree
>> that SSL does a reasonable job of preventing eavesdropping.
> 
> I can see a lot of resistance from customers told they now need to
> buy and maintain a certificate from a CA just to run a webserver.
> 
> Sure they can run a self-signed cert, but that doesn't fulfil the
> goal of giving the user security.

Could we cut the FUD about needing to pay for certs? There are indeed
providers of free certificates (I won't mention names for fear of
being tarred with a marketing brush).

And SSL/TLS is not *necessarily* tied to PKI, either.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Belshe <[email-masked]>
Date: Mon, 26 Mar 2012 11:17:24 +0200

On Mon, Mar 26, 2012 at 10:56 AM, Adrien W. de Croy <[email-masked]> wrote:

> Cc: "patrick mcmanus" <[email-masked]>;"[email-masked]" <
> [email-masked]>
> On Mon, Mar 26, 2012 at 10:10 AM, Roy T. Fielding < <[email-masked]>
> [email-masked]> wrote:
>
>> >> In message<CAAbTgTu7qbPiREWRRqFddgoko0FCt0jmxR=<[email-masked]>
>> [email-masked]>
>> >> , Brian Pane writes:
>> >>
>> Web protocol design should serve them first. They have an unmet expectation
>> protocol secure all the time; the mixed- content vulnerabilities of HTTP/1
>> make that clear to me.
>>
>>
> I can see a lot of resistance from customers told they now need to buy and
> maintain a certificate from a CA just to run a webserver.
>

This is just not true.  Its free to get and has been for a while.

>
> Sure they can run a self-signed cert, but that doesn't fulfil the goal of
> giving the user security.
>
> There are so many devices running an HTTP server now which don't have the
> option to put in a cert.  E.g. web admin on my ADSL modem.
>

Well, your existing device doesn't support HTTP/2.0 either.  So maybe we
shouldn't build HTTP/2.0? :-)

Seems like a chicken and egg problem.

> my biggest concern is the mandatory nature of SSL/TLS in the proposal.

Let's be clear - the current SPDY draft does not require SSL.

> Otherwise we will do it badly.  Which do you prefer?  We _will_ do it.

No disagreement here.

> Because customers insist we do.

We need to differentiate corporate and consumer requirements here.
 Consumers are not asking you to do this.  Private networks and
corporations are.  Both are legitimate.

Mike

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 09:22:03 +0000

------ Original Message ------
From: "Peter Saint-Andre" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "Mike Belshe" <[email-masked]>;"Roy T. Fielding" 
<[email-masked]>;"patrick mcmanus" 
<[email-masked]>;"[email-masked]" <[email-masked]>
Sent: 26/03/2012 10:03:30 p.m.
Subject: Re: SPDY = HTTP/2.0 or not ?
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
  
providers of free certs who
  
a) verify the identity of the entity they issue the certificate to
b) have a root cert that's sufficiently well deployed and trusted to be 
usable
  
?  I'd be keen to know more.
  
if not a (which is incompatible with free) then is it really security?
>And SSL/TLS is not *necessarily* tied to PKI, either.
  
OK.  so no private key?  Just some shared secret then?

>From memory it's fairly painful to get SSL working in a web server.  Do 
we really wish to inflict that pain mandatorily on every web server 
operator?
>
>
>Peter
>
>- --
>Peter Saint-Andre
>https://stpeter.im/
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.8 (Darwin)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
>iEYEARECAAYFAk9wMOIACgkQNL8k5A2w/vzHhwCglS0mTAc8vmtaTELnJXtsiDXt
>GwYAnjO/WlyYE+PCs1SgPVB+19Aav0y6
>=cS8p
>-----END PGP SIGNATURE-----
>
>
>

---

From: Brian Pane <[email-masked]>
Date: Mon, 26 Mar 2012 02:22:11 -0700

> protocol for p0rn, newspapers and blogs.

And the majority of users probably don't consider HTTP an unsecure
protocol for email, social networking, search, or banking...mostly
because they don't know what a "secure protocol" is, or even what
a "protocol" is.  And they shouldn't have to know those details.

For HTTP/2.0, we're talking about a protocol that thousands of
people will implement.  And then millions of people will deploy
those implementations to create websites.  And billions of people
will use those websites during the protocol's active lifetime.  If we
convince ourselves that securing the transport is too onerous for
the thousands, or too inefficient for the millions, we'll be missing
a chance to better harden the web on behalf of the billions.

-Brian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 09:39:27 +0000

>I disagree strongly. What users read and view should be private at this 

But that is what _you_ think, it is not what the _users_ think.

While your belief system may be wholesome and self consistent, you should
not assume that everybody else shares it, absent very strong statistical
evidence.

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 09:43:48 +0000

------ Original Message ------
From: "Mike Belshe" [email-masked]
> the option to put in a cert.  E.g. web admin on my ADSL modem.
 
 Well, your existing device doesn't support HTTP/2.0 either.  So maybe 
 we shouldn't build HTTP/2.0? :-)

My point is that these types of deployment will exist in future, yet 
may not be capable of running SSL (or at least installing a cert) for a 
number of reasons (maybe not even technical, but more likely 
administrative).
  
If we want HTTP/1.1 to eventually disappear, we need to cater to these 
applications.
  
If we don't, then are we improving things?
  
 > but that doesn't mean we should leave it wide open either.  And we 
 > can solve much of the eavesdropping problem right now.  So the 
 > question is really - why wouldn't we?
>  

OK thanks.  I haven't read the recent drafts.  My understanding 
(obviously out of date) was that SSL was required to negotiate the 
support for SPDY by the server.
 
 No disagreement here.

  
  
the ones who pay us are the corporates.
  
Adrien

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 09:49:53 +0000

In message <[email-masked]>
, Brian Pane writes:

>If we

...but on the other hand, we might see the fruits of our labors actually
used by people, if we try to deliver tools, rather than policies.

The choice of crypto or no crypto is for the HTTP-service provider to
decide, it is not for us to decide on their behalf.

We can offer the tools, we can encourage the use of them, but we have
neither moral nor political authority to mandate use of cryptograhpy
by people who do not want it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 11:55:56 +0200

On 3/26/12 11:22 AM, Adrien W. de Croy wrote:
> 
> ------ Original Message ------ From: "Peter Saint-Andre"
> <[email-masked]> To: "Adrien W. de Croy" <[email-masked]> Cc:
> "Mike Belshe" <[email-masked]>;"Roy T. Fielding" 
> Sent: 26/03/2012 10:03:30 p.m. Subject: Re: SPDY = HTTP/2.0 or not
> ? On 3/26/12 10:56 AM, Adrien W. de Croy wrote:
> 
> 
>>>>> 
>>>>> alternatives to SSL on the table right now.  Most people do
>>>>> agree that SSL does a reasonable job of preventing
>>>>> eavesdropping.
>>>>> 
>>>> 
>>>> 
>>>> I can see a lot of resistance from customers told they now
>>>> need to buy and maintain a certificate from a CA just to run
>>>> a webserver.
>>>> 
>>>> Sure they can run a self-signed cert, but that doesn't fulfil
>>>> the goal of giving the user security.
>>>> 
> 
> 
> Could we cut the FUD about needing to pay for certs? There are
> indeed providers of free certificates (I won't mention names for
> fear of being tarred with a marketing brush).
> 
> 
>> a) verify the identity of the entity they issue the certificate
>> to b) have a root cert that's sufficiently well deployed and
>> trusted to be usable
> 

You can check the cert at the URL in my sig.

>> OK.  so no private key?  Just some shared secret then?

See for example the DANE WG:

http://tools.ietf.org/html/draft-ietf-dane-protocol

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 10:15:12 +0000

------ Original Message ------
>You can check the cert at the URL in my sig.
  
Ok thanks.
  
In the end though, even if the certificate itself isn't charged for, 
there's still a cost involved in obtaining and installing it.
  
Generating a signing request etc, importing the certificate and 
managing the private key.
  
These add a significant requirement to many HTTP server deployment 
scenarios, not the least in terms of level of knowledge of the person 
doing it.
  
>http://tools.ietf.org/html/draft-ietf-dane-protocol
  
thanks again!  

Adrien
>iEYEARECAAYFAk9wPSwACgkQNL8k5A2w/vwUXwCgkMGTKxKbRqiK8mBJi9izlkzi
>djQAoLXQzTsvRCVRq1CJTqpfiVQRUoHM
>=LE6/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 10:19:52 +0000

In message <emb750f05b-e5c7-4cb5-8be6-6718344b0784@boist>, "Adrien W. de Croy" 

>scenarios, not the least in terms of level of knowledge of the person 

Not to mention the almost certainty that some low-end vendor will
deliver millions of "web-enabled" gadgets with the same built in cert.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 26 Mar 2012 12:21:41 +0200

On Mon, Mar 26, 2012 at 11:49 AM, Poul-Henning Kamp <[email-masked]>wrote:

> In message <
> [email-masked]>
> , Brian Pane writes:
>
> >If we

Your theory is provably false today:

Google, Twitter, Amazon and others have *already* deployed SPDY, even in
its current, early adopter form.  These deployments are clear evidence that
there is demand.   At the same time, all of these vendors would like to see
the features of SPDY made available in a standardized form through IETF.

> decide, it is not for us to decide on their behalf.

Nobody ever said we'd take away an unsecure path.  I just don't want it to
be the default.  Make security opt-out rather than opt-in.

How much global legislation about liability for accidentally leaked
information do you need before you'll believe that we have a responsibility
here?

> by people who do not want it.

Keep in mind the SPDY draft does not require SSL.

Mike

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 10:24:49 +0000

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

>Google, Twitter, Amazon and others have *already* deployed SPDY, 

I think we can fairly and squarely say that those three named examples
are more than 5 sigma out from the average web-server.

>These deployments are clear evidence that
>there is demand.

I don't doubt there is _demand_, but that demand is not a mandate nor
does it justify an edict.

I fully think SPDY should be standardized, but I don't think it should
be named HTTP/2.0.

>information do you need before you'll believe that we have a responsibility

We have a responsibility to deliver good tools, we have no mandate to
enforce (our pet) policy.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 12:24:18 +0200

On 3/26/12 12:15 PM, Adrien W. de Croy wrote:
> <[email-masked]>
>>>>>>> alternatives to SSL on the table right now.  Most
>>>>>>> people do agree that SSL does a reasonable job of
>>>>>>> preventing eavesdropping.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> I can see a lot of resistance from customers told they
>>>>>> now need to buy and maintain a certificate from a CA just
>>>>>> to run a webserver.
>>>>>> 
>>>>>> Sure they can run a self-signed cert, but that doesn't
>>>>>> fulfil the goal of giving the user security.
>>>>>> 
>>>>>> 
>>> 
>>> indeed providers of free certificates (I won't mention names
>>> for fear of being tarred with a marketing brush).
>>> 
>>> 
>>> 
>>>> 
>>>> a) verify the identity of the entity they issue the
>>>> certificate to b) have a root cert that's sufficiently well
>>>> deployed and trusted to be usable
>>>> 
>>>> 
> In the end though, even if the certificate itself isn't charged
> for, there's still a cost involved in obtaining and installing it.
> 
> scenarios, not the least in terms of level of knowledge of the
> person doing it.

It might seem easier and cheaper for me if I don't have to install a
lock on the door to my house, fumble for the keys when I get home at
night, etc. But actually it's easier and cheaper for me if random
people can't walk into my house. There ain't no such thing as free
security.

(Oh, and these messages are all as individual, not area director.)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 10:35:34 +0000

------ Original Message ------
>people can't walk into my house. There ain't no such thing as free
  
a lot of these points are moot, since Mike has informed us the latest 
SPDY draft does not mandate encryption.
  
Re your house simile... we're used to houses and doors and locks.
  
I can't imagine the pain of trying to support non-technical home users 
through the process of securing a web server with SSL.
  
So I think we can assume that many deployments will opt out.
>(Oh, and these messages are all as individual, not area director.)
  
ok no prob - 1 week to go?
  
Adrien
>iEYEARECAAYFAk9wQ9IACgkQNL8k5A2w/vzFEACg0Vdrvmi/FoEMChWJImhgUlK1
>v4kAoOLgclSi2ky4gMUBxJidUPAfXi0F
>=cF8V

---

From: Henry Story <[email-masked]>
Date: Mon, 26 Mar 2012 12:41:55 +0200

> people can't walk into my house. There ain't no such thing as free

Especially on the internet where we are all neighbours...
Adding security (even weak one) would provide an exponential boost to security
on the internet. Currently nearly every web page can be hijacked with a man in the
middle attack that changes URLs to point to different servers. 

Having said that to cater for use cases where security is not an issue, yet
to make sure that the groups working on SPDY to do not forget security, I think
having SSL be opt out that is a good idea. It satisfies both use cases, but
helps make sure the groups communicate more closely than they would otherwise do.

btw, I am in switzerland in an identy conference a few days this week, and will
be in Paris towards the end of the week again. It would be nice to meet up.

Henry

> (Oh, and these messages are all as individual, not area director.)

Social Web Architect
http://bblfish.net/

---

From: patrick mcmanus <[email-masked]>
Date: Mon, 26 Mar 2012 13:39:15 +0200

> helps make sure the groups communicate more closely than they would otherwise do.

none of this needs to be decided now, of course. But having any path for 
mixed-content (e.g. https html with http scripts or even images) is 
potentially troublesome - we've seen that repeatedly for the last 10 
years. Content owners do not understand the risks they are exposing 
their users to by using insecure protocols. The web would be better 
without that vector.

I know that not every use case is about the web, but it seems at least 
plausible that the best path is to secure everything rather than relying 
on the deployer's judgment which has a bad failure mode.

---

From: Ross Nicoll <[email-masked]>
Date: Mon, 26 Mar 2012 12:41:16 +0100

>if not a (which is incompatible with free) then is it really security?

I've used StartSSL ( http://www.startssl.com/?app=1 ) as a "better than
nothing" option for budget-less projects, before. Their certificates seem
fairly widely deployed (we certainly never had an issue with it).

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 26 Mar 2012 13:42:33 +0200

On 3/26/12 1:41 PM, Ross Nicoll wrote:
>> <[email-masked]> To: "Adrien W. de Croy" <[email-masked]> 
>> <[email-masked]>;"[email-masked]"
>> <[email-masked]> Sent: 26/03/2012 10:03:30 p.m. Subject: Re:
>> SPDY = HTTP/2.0 or not ?
>> 
> I've used StartSSL ( http://www.startssl.com/?app=1 ) as a "better
> than nothing" option for budget-less projects, before. Their
> certificates seem fairly widely deployed (we certainly never had an
> issue with it).

As I said, check the cert at https://stpeter.im/ ;-)

---

From: Ross Nicoll <[email-masked]>
Date: Mon, 26 Mar 2012 13:04:42 +0100

On 26/03/2012 11:21, Mike Belshe wrote:

> Nobody ever said we'd take away an unsecure path.  I just don't want it
> to be the default.  Make security opt-out rather than opt-in.
> 
> information do you need before you'll believe that we have a
> responsibility here?

My interpretation of many of the arguments was that there should be no
insecure option. I'd be happy to see a secure by default protocol with
an option to force it to plain-text (or similar).

I suspect if the protocol was secure-only, people would either not adopt
it (and stick to HTTP 1.1) or would create their own variants with
security disabled (likely resulting in multiple slightly incompatible
protocols). I would consider either of these outcomes worse than letting
people shoot themselves in the foot with a protocol that tries to
outline the risks to them.

Ross

---

From: Henrik Frystyk Nielsen <[email-masked]>
Date: Mon, 26 Mar 2012 21:35:11 +0000

FWIW, I completely agree with this -- another set of scenarios include the many connected devices large and small that come with an HTTP server baked in. It would be infeasible or undesired to require SSL for many of these devices. 

Henrik

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]] 
Sent: Monday, March 26, 2012 1:10 AM
To: patrick mcmanus
Cc: [email-masked]
Subject: Re: SPDY = HTTP/2.0 or not ?

On Mar 26, 2012, at 9:44 AM, patrick mcmanus wrote:

>> In 
>> message<CAAbTgTu7qbPiREWRRqFddgoko0FCt0jmxR=[email-masked]
>> l.com>
>> , Brian Pane writes:
>> 

I've never considered SSL to be a means of securing the protocol.
It does a decent job of hiding the exchange of data from passive observers, but the way that typical user agents handle certificate management lacks what I would consider a secure protocol.

In any case, the notion that every user wants a secure protocol is irrelevant.  There are many examples of HTTP use, in practice, for which SSL/TLS is neither desired nor appropriate.  Even simple things, like the exchange that Apple devices use to discover network access point logins, cannot work with an assumption of SSL/TLS.  Likewise, many uses of HTTP are in kiosks, public schools, libraries, and other areas for which your concern as a user is less important than the organization's responsibility to prevent misuse.

There are ways to have both a secure protocol and visibility for intermediaries, but we don't have to agree to any of these "requirements"
up front.  If the protocol proposals can't stand for themselves, then I have no need for a new protocol.

....Roy