Re: HTTP 2.0 mandatory security vs. Amateur Radio

I don't even think we can get the right people to admit that it is broken
(there are a lot of vested interests who have strong incentives to maintain
status quo).

But I do agree-- the internet today is broken in many respects:
  you can't deploy anything other than a subset of http/1.1 on port 80
  middleboxes prevent better TCP implementation deployments (or make it
substantially more difficult to do) by enforcing rules that are not
actually defined for TCP
  the packet forwarding plane for the internet provides poor (if any) flow
isolation, resulting in either high packet loss (small buffers), or
bufferbloat (large buffers).
  only a few well-known ports actually are reliable
  .. and I can go on and on and on :)

I'm an engineer. I don't mind admitting to problems, nor do I particularly
mind being wrong when it implies that a better understanding has been
achieved (or a better outcome).

When I think about how we got here, I'm fairly certain that there is no
MUST we could put into a document or spec, and there is no social
engineering that would have prevented us from reaching the state that we're
in today w.r.t. middleboxes.
That implies that the solution-space is limited to things that we can
ensure mechanically.

On Thu, Nov 14, 2013 at 11:30 PM, Bruce Perens <> wrote:

>  On 11/14/2013 11:05 PM, Roberto Peon wrote:
>  Given that putting everything under one roof is infeasible/impossible
> (the internet spans many different jurisdictions/countries), and given that
> we cannot dictate what people deploy or not, the one technical approach
> that has the highest chance of success is the one where content is
> encrypted.
> Do I love this? Nah. But I've been unable to come up with a better plan
> that would work. Can you come up with a plan that will work reliably?
>  I definitely don't want to go back to Ma Bell running everything. But it
> seems to me that just saying that an encrypted tunnel to one port must be
> the solution for everything is a complete abdication of leadership. Instead
> of being the protocol designers of the internet, we become the rats in the
> walls who sneak all of our new inventions through a little encrypted hole
> in what we made.
> We broke the internet. It was because of our tremendous success. It grew
> so big that its size and inertia froze it and made further protocol
> development impossible.
> Getting out of this problem starts with admitting it, publicly, to
> everyone. It then will be necessary to chart the requirements that will
> prevent this from happening again, and then to promote and certify the
> implementations of those recommendations.

Received on Friday, 15 November 2013 07:50:27 UTC