Subject: Re: [arch-d] deprecating Postel's principle - considered harmful

From: Keith Moore <[email-masked]>
Date: Thu, 9 May 2019 21:59:38 -0400

I'm another person who really doesn't want to see an RFC of the form 
"Jon Postel was wrong".   Part of the problem is that he was right in so 
many ways, that to single out in a particular way that he was "wrong" 
[*], conveys entirely the wrong impression.   Even if he was "wrong" [*] 
about the sentence most often attributed to him today.

[*] or lacking perfect foresight, or is being misunderstood, or taken 
out of context, or ...

Depending on where you mark the start of the Internet, it and the first 
protocols have existed for around forty years.   It's been around for so 
long, longer than most of its users have been alive, that it's easy to 
take for granted the accumulated wisdom that went into producing it - 
both Jon's contributions and others'. That's not to say that they got 
everything right, and today we're painfully aware of some of the 
shortcomings.    But that they got it working well enough to endure for 
40 years and counting, and to be able to evolve (to some extent) to 
continue to serve the whole world today, was a tremendous 
accomplishment.   Of course, different bits of wisdom become more (or 
less) applicable (or need to be interpreted in different contexts) at 
different points of evolution and scale.

I seriously doubt that Jon would have wanted us to be stuck in the past 
and stop learning.   But neither should we discard hard-won lessons of 
the past.

A lot of additional hard-won wisdom has been cited in this thread, and I 
think it could do a service to try to capture it and place it in the 
context of the earlier accumulated wisdom.

Keith

p.s.  I've often said that "the web" was optimized for deployability.   
Lots of "the web" was poorly designed, IMO, but enough of it was 
designed just well enough to make it attractive to users, and that very 
attractiveness is what has fueled the effort required to improve it.   A 
similar statement could be made of the Internet itself.  As an engineer, 
this bugs me a bit, but I think it's reality.   It's often said that the 
perfect is the enemy of the good, but maybe sometimes, the good is the 
enemy of the deployable.   Being liberal in what you accept is similar, 
in a sense, to optimizing for deployability.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 May 2019 16:47:34 -0400

> in a sense, to optimizing for deployability.

Damn right it was. Deployability was the primary consideration. We did not
use SGML because any of us liked it or considered it to be a solid
technical specification. We hated it and we though it was crap. The reason
we went there was that we needed buy-in from the publishing world.

But equally importantly, we broke a lot of what people thought were the
rules. I knew that there wasn't a Content-Length header in MIME when I
added it to the HTTP spec and so did Tim. But we pretended it did because
we needed to make the POST method work and we were not going to introduce
mandatory content body framing or SMTP type escaping.

A lot of the reason that the Web is the way it was is that the exponent
kicked in the growth curve while we were still trying to work out the
architecture. And the Web grew much much faster than the bandwidth needed
to serve it. Back in 1994, caching proxy servers were essential
infrastructure needed to make the Web work. That isn't the case now. In
fact TLS-everywhere is rapidly making them obsolete.

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2019 16:44:18 -0500

On Fri, May 10, 2019 at 04:47:34PM -0400, Phillip Hallam-Baker wrote:
> > [...]

Thankfully you did add chunked transfer-encoding.

> fact TLS-everywhere is rapidly making them obsolete.

Is that so?  Caching proxies merely need to become MITM proxies.  Those
exist, and in many corporate environments that require web access and
data loss protection (DLP), they must exist.  I know because I use one,
and also I maintain one (though the one I maintain is not a caching
proxy).  Middleboxen will be with us forever.

Now, an MITM proxy that exists to enforce policy and implement DLP
needn't be a _caching_ proxy, so perhaps your statement is correct after
all!   :^)

But seriously, I don't expect proxies to go away.  I expect them to be
MITM proxies.

I'd rather that, instead of MITM proxies, clients used HTTPS to speak to
the proxy and did not use CONNECT for HTTPS resources, but that's not
likely to happen (and even so, if the user-agent must use client
certificates, it will have to use CONNECT), so MITM proxies they shall
have to be.

Nico
--

---

From: "John Levine" <[email-masked]>
Date: 10 May 2019 21:48:08 -0000

In article <[email-masked]>,
>fact TLS-everywhere is rapidly making them obsolete.

Seems to me they've been replaced by Akamai and other CDNs.
-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 May 2019 18:20:45 -0400

> Thankfully you did add chunked transfer-encoding.

Chunked came after keep alive which I proposed at the first Web Conference
together with a different chunking and was told it wasn't needed. Then
people started going heavy on images and TCP teardowns started to be the
limiting issue.

> proxy).  Middleboxen will be with us forever.

Of course. The part that is going away though is the part we were focused
on in 1994-1996 because the Internet was melting under the load.

MITM proxies introduce their own horrors and they are an example of the
cost of trying to remain principled in an unprincipled world. We could do
MITM in a much better way than we have ended up with. But we can't come to
consensus on a protocol of that sort.

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 May 2019 17:47:47 -0500

> on in 1994-1996 because the Internet was melting under the load.

Ah yes, that's done, thankfully.  Indeed, the network is now faster than
the servers, so we scale out horizontally as much as possible.

> consensus on a protocol of that sort.

Consensus isn't the problem.  The problem is that HTTP/1.x was so
trivial to implement (bash + printf + nc can do it) that there are too
many "stacks" in which to implement something new, so it can't be done.

This is also why 3xx redirect-based authentication methods are winning
over as-originally-intended 401 / WWW-Authenticate / Authorization
methods.  It's easier to implement redirect chasing than to implement a
pluggable authentication method framework.  (Also, it's easier on server
devs to use redirects.)  I just wish 3xx and 401 weren't mutually
exclusive.  I posted to [email-masked] a few weeks ago about that got no
replies, sadly.

There's just no way to do better when we'd have to fix a few thousand
clients and a dozen or so proxies.  ETOOHARD is an understatement.

Nico
--