Subject: Re: Rechartering HTTPbis

From: Ray Polk <[email-masked]>
Date: Tue, 24 Jan 2012 00:53:46 -0800 (PST)

+1 phk

Why is SPDY consistently compared to HTTP instead of https?  How does one midtier cache public stuff with encrypted headers?

----- Original Message -----
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Sent: Tuesday, January 24, 2012 1:16:10 AM GMT -07:00 US/Canada Mountain
Subject: Re: Rechartering HTTPbis

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

>HTTP/2.0
>--------

I am going to play the devils advocate and throw a number of spanners
in the general direction of the works:

>[...]we'll start by asking for proposals, considering them and selecting
>one based upon the traditional IETF criteria of rough consensus and
>running code.

> Goals and Milestones:
>
>   Done        First HTTP/1.1 Revision Internet Draft 
>
>   Done        First HTTP Security Properties Internet Draft 
>
>   Feb 2012    Working Group Last Call for HTTP/1.1 Revision 
>
>   Feb 2012    Working Group Last Call for HTTP Security Properties 
>
>   Apr 2012    Submit HTTP/1.1 Revision to IESG for consideration as a 
>               Proposed Standard 
>
>   Apr 2012    Submit HTTP Security Properties to IESG for consideration as 
>               Informational RFC

Where is that "ask for proposals yadda, yadda, yadda..." stuff ?

>   May 2012    First HTTP/2.0 Internet Draft
>
>   May 2013    Request Last Call for HTTP/2.0
>
>   Jul 2013    Submit HTTP/2.0 to IESG for consideration as a Proposed
>               Standard

One year ?  Yeah, right, as if.

Looking at the above, the only activity I credibly see us perform
is to beatify SPDY.

>* More efficient use of network resources; in particular, reducing the
>  need to use multiple TCP connections

So we're just going to ignore that SCTP already solved this problem
and many other problems, because we just need this as hook to approve SPDY.

>* Ability to be deployed on today's Internet, using IPv4 and IPv6, in the
>  presence of NATs

Apart from "no reverse connections" I have no idea what this means.

>* Maintaining HTTP's ease of deployment

I think this is fundamentally at odds with SPDY's design.

You can write a HTTP webserver in any language or facility that can
do ASCII text, I have even seen such a webserver written in INTERCAL.

SPDY has a very high barrier of entry, zlib compression and a lot of
state, so what exactly do we mean ?

>* Reflecting modern security requirements and practices

Ohh, interesting:  Security against who ?  Security against your
ISP or mobile carrier injecting unwanted ads ?  Security against
your government censoring your web-experience ?  Security against
cross-site-scripting ?  Security against potempkin CA's ?

I could see the discussions take more than a few months, just on this.

>In documenting this protocol, the Working Group must:
>* Meet the goals specified above
>* Make it possible to pass through a HTTP/1.1 message with reasonable
>  fidelity; i.e., to implement a gateway to or from HTTP/1.1

Ok, any protocol worth its salt can pass through a blob of bytes and
call it "a passed through HTTP/1.1 message", but what's the point ?

Where is it going to come from and where is it going to go ?

And why ?

>* consider the needs of a variety of HTTP implementers and users
>  (such as "back-end" or "web api" uses of HTTP, servers and intermediaries)

Ohh, so we are going to cater to "intermediaries" who want to censor the
web ?  I guess we were talking "job-security" then ?

>* Address HTTP proxy and CDN infrastructure requirements
>
>Changes to the existing semantics of HTTP are out of scope in order to
>preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
>request chain. However, the effort may define new semantics to further the
>goals above, along with suitable extensibility mechanisms for defining
>additional semantics.

So, we are not going to actually solve any of the semantic problems
we created, we're just going to wrap the usual mess in a compressed
protocol called SPDY ?

>This work will be known as "HTTP/2.0", unless the Working Group
>determines that this isn't suitable (e.g., for interoperability).

I really don't think it qualifies for that pretentious name, because
all it is set up to be, is tunneling HTTP/1.1 more efficiently
through the tubes.

In my mind, the effort sketched out would be correctly titled
"Beatify the SPDY protocol as a carrier of HTTP/1.1 traffic"

HTTP/2.0 would in my mind be an attempt to actually improve the
protocol, possibly going as far as replacing everything but the
first line which we would have to keep, to ensure the ability
to interoperate with earlier HTTP protocols)

Please be honest...

-- 
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: John Stevens <[email-masked]>
Date: Thu, 26 Jan 2012 18:06:17 +0000

Ø  Its not clear where in the charter proposal you are getting the idea

Ø  from that this is a redesign of network application programming APIs.

I didn't get that idea from the proposal.  My point was that IMO HTTP/HTML has been kludged into a network transparent application programming framework (NTAPF), and maybe it is time to acknowledge that, and make sure that work on HTTP 1.2 (or 2.0, or what have you) explicitly and consciously acknowledge that the time has come for a split.  In 1.2, return to the idea of HTTP/HTML as a public information/content delivery service that has no interactivity requirements and requires only minimal security.

Then start an entirely new group dedicated to creating a valid and well thought out NTAPF.

Ø  Please no. Intermediaries often get caught in the middle (pun intended)

Ø  of disputes about website A credentials being given to untrustworthy

Ø  website B accidentally because the client was using SSO to website A.

Websites.  Exactly so!  WEBSITES.  You are still thinking in terms of kludging security into/onto a system that is philosophically, and very fundamentally not designed for NTAPF.

Kerberos is actually designed for SSO, and the problems that (I think, but could have misunderstood you) you raise are due to starting with this premise of kludging K5 onto web sites.  The Kerberos domain model would actually be perfect on the wild net, solving the very problems you raise, IF not forced into the "web application" model.

Thanks for your rely.  Not that I expected any one to take me seriously, and indeed, the idea I put forth is almost certain to be seen as heresy, so I expected only to be ignored.  Feel free to take it as a partially serious, partially comic statement.

John S.

   "A kludge evolves from bad idea implemented to make schedule, to tradition, to finally becoming a fixed and immovable fact because we built so much on top of it."