Re: Rechartering HTTPbis

On 25/01/2012 9:02 a.m., John Stevens wrote:
>
> While I am all for cleaning up ambiguous language, adopting industry 
> standard extensions and clarifying conformance requirements, I would 
> respectfully suggest that we re-consider the meaning of HTTP (Hyper 
> Text Transfer Protocol).
>
> The world has long since used HTTP to do far, far more with HTTP than 
> its original design intent. While this is a testament to the ingenuity 
> and inventiveness of human beings, it is also the largest public 
> demonstration of an anti-pattern I can think of. A huge industry has 
> evolved around the process of band-aiding, adding baling wire, duct 
> taping and out-right kluding HTTP and HTML into an application 
> programming framework.
>
> I must admit I’ve long described what has occurred as “the 
> re-invention of X11 . . . done badly, even less securely, and with 
> large gaping holes in it”, yet even I nearly fell out of my chair 
> laughing when I read the SPDY spec. Give the inventors their due: they 
> either have knowledge of X11, or they were creating one of the best 
> technical homages I’ve ever seen.
>
> Expecting no support what so ever, and knowing how unlikely this is, 
> may I (again, very respectfully) suggest that HTTPbis focus on 
> maintenance (that it produce HTTP 1.2, not 2.0), and that a new 
> working group be formed that actually address the concept of network 
> transparent application programming as a real thing in its own right? 
> While some of the components and technologies that have been developed 
> during the great kludge of HTTP/HTML into “web applications” will 
> almost certainly be re-usable, designing from the standpoint of 
> actually focusing on a network transparent application programming 
> framework might be hugely beneficial.
>

Its not clear where in the charter proposal you are getting the idea 
from that this is a redesign of network application programming APIs. 
HTTPbis has not to my knowledge ever stepped foot into that mess 
(individual members maybe but not the WG). Although we do work to 
solidify the base protocol the make use of. Much asn TCP and IP WG 
solidify and improve the layers underneath HTTP.

My reading of it shows a proposal for syntax changes that make the 
existing messages easier to transmit on the wire. As implementer of an 
intermediary I could not care less what type of application kludges are 
implemented using RESTful semantics of HTTP. But the current protocol is 
somewhat difficult and quite slow for all the software involved to 
handle. Particularly for intermediaries, which have to seamlessly handle 
*all* of those kludges not just the specific type of applications the 
server or client is built to process.

> Along those lines, and as my first suggestion, I would like to vote 
> for making Kerberos 5 a fundamental requirement of the system. OK, GSS 
> if you insist, but security is job one, and single sign on would be a 
> HUGE selling point for adoption of a new 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.
SSO has only ever been a good idea from the LAN administrators viewpoint 
(less trouble managing N peoples logins) and is a somewhat outdated 
concept. Users are aware of and happy to use e-wallet and password 
collection models of security which are also fairly easily automated by 
the clients doing auth.

Kerberos as a weaker hop-by-hop alternative for TLS is an interesting 
idea worth looking at (we offer this already in Squid peering links). As 
are message signing and similar models.

But SSO should not be considered a viable security mechanism for use the 
length and breadth of the Internet. Take a look at the number of threats 
in the OAuth threatmodel document which have the countermeasure of "be 
good or this breaks" for a demonstration of SSO in the wild Net.

> OK, I’m done being silly now. We can all go back to our normal mode of 
> operation.
>
> John S.
>
> “Those who do not learn history are doomed to re-invent it. Badly.”
>

+1 to that quote.

AYJ

Received on Wednesday, 25 January 2012 14:46:52 UTC