Re: [hybi] Why not just use ssh?

"Shelby Moore" <shelby@coolpage.com> Wed, 01 September 2010 01:36 UTC

Return-Path: <shelby@coolpage.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC7623A68D7 for <hybi@core3.amsl.com>; Tue, 31 Aug 2010 18:36:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.05
X-Spam-Level:
X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[AWL=-1.051, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOMCzzBTt9JI for <hybi@core3.amsl.com>; Tue, 31 Aug 2010 18:36:16 -0700 (PDT)
Received: from www2.webmail.pair.com (www2.webmail.pair.com [66.39.3.96]) by core3.amsl.com (Postfix) with SMTP id 935F83A68A5 for <hybi@ietf.org>; Tue, 31 Aug 2010 18:36:15 -0700 (PDT)
Received: (qmail 44656 invoked by uid 65534); 1 Sep 2010 01:36:42 -0000
Received: from 121.97.54.174 ([121.97.54.174]) (SquirrelMail authenticated user shelby@coolpage.com) by sm.webmail.pair.com with HTTP; Tue, 31 Aug 2010 21:36:42 -0400
Message-ID: <dfc5f766219af892ababdd83729ce384.squirrel@sm.webmail.pair.com>
Date: Tue, 31 Aug 2010 21:36:42 -0400
From: Shelby Moore <shelby@coolpage.com>
To: Eric Rescorla <ekr@rtfm.com>
User-Agent: SquirrelMail/1.4.20
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Cc: hybi@ietf.org
Subject: Re: [hybi] Why not just use ssh?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: shelby@coolpage.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Sep 2010 01:36:20 -0000

Adam Barth wrote:
> Right.  We're talking about what APIs a browser exposes to arbitrary
> web content.  I don't want to expose the non-TLS version as an API
> inside a web browser because I'm not convinced it can't be used by
> attacker.com to mount a cross-protocol attack.

Seems to me that is a weak argument relative to the amount of damage it
will do if we burden the browser will perfection against cross-protocol,
as explained below in my response to Eric.

> Cross-protocol attacks are quite subtle and generally take years to
> uncover.  Your statement is roughly equivalent to "protocol XYZ uses
> encryption, it might be secure against man-in-the-middle attacks,
> right?"

HTTP isn't secure against MITM, so by your logic, we should turn off HTTP?



I tried to resolve this in private with Eric, but he said he did not have
time to fully understand and engage my points privately.


> Shelby Moore wrote:
>> >> I think we need to deliver on HTTP Upgrade.
>> >
>> > TLS works over any port.  The point of using TLS alone is to block
cross-protocol attacks.  If we provide both TLS and non-TLS options,
the attackers will choose the non-TLS option for their attackers
whereas the folks who actually want to connect to the server more
than 60-some percent of the time will use the TLS option.  Offering
both is a lose-lose.
>>
>> Nothwithstanding that I think cross-protocol attacks are the fault of the
>> target protocol, do not forget that browsers can allow users to turn
off or opt in to certain features.
>>
>

Eric Rescorla wrote:
> I don't see the relevance of this.


You chopped off the part of my prior message that explained the relevance
as follows:

=======================================================
I am reminded of my "don't go chasing shadows" post about security:

http://www.ietf.org/mail-archive/web/http-state/current/msg00939.html

Blaming security holes on the messenger instead of on the actual hole
(injection point), or not hardening behind the firewall is analogous to
hardening a castle more by making the walls ever higher and the doors ever
smaller or more difficult to open.

The end result is starvation.

The most security is to break yourself into million parts and distribute
yourself.

So moving the security farther from the center is the answer.

We don't want to lock ourselves inside with the security holes, we expose
the holes so we can be outside and prosper, and so the holes will get
identified and fixed.

It goes back to "more eyeballs = shallower bugs" (Cathedral and Bazaar
model). It is all about maximizing the # of mutations per evolutionary
generation. Wasn't there a math book that said "thou shall go forth and
multiply"?

Conflation (blaming something for something else, or trying to
implementation one thing by implementing multiple things) is worse than
wasteful, it is actually classified as evil in some ancient math books
(Parable of the Talents).
=======================================================


> The extant protocols have whatever set of security properties they have.


If someone builds popular way to send email by requesting an image url
with GET params, does that mean it is a protocol attack against HTTP so we
will apply SOP to images because it could be used to send spam?

How many examples of bad server programming do you need me to give before
you realize it is insanity to trap ourselves inside the prior analogy of
the castle walls by forcing the perimeter clients to defend the bad
servers?

I did not denounce SOP for client side resources.

I said SOP is not the security hole for server requests. I have explained
at the sub-links, that the security hole for cross-protocol are the bad
servers and protocols. And the security hole for CSRF payloads are the
injection points of the bad scripting which has nothing to do with
cross-origin. Refer to the links I provided (I can't retype them all
here).

We can't have a situation where the browser become surety for the servers
of the world. That will only encourage servers and protocols to become
more lax and never be fixed. This means the morass of badness will
compound until we end up in abject failure.  We can't designing things
where we are handcuffed by every bad thing anyone every did in history. It
is the epitome of socialism. Capitalism is to let each entity be
responsible for itself.  Do you know where socialism ends every time in
history? Horrific failure and misery. I am begging you please think this
over carefully. Don't reply quickly.  Go reflect on it for a week.



> The browser security model is designed to prevent Web sites from exploiting
> them.


It should apply to the client side resources only.  The servers must
protect themselves. If the castle analogy of starvation is not sufficient
to convince you, I will mathematically justify below.


> I don't consider (and as far as I can tell, pretty much nobody else
considers)
> shipping a solution that threatens the security of those protocols to be an
> option.


I know some experts would prefer the starvation (central control) model
aka Almost-Better-Than-Nothing security, but I understand that
self-organization is the way nature solves chaos:

http://en.wikipedia.org/wiki/Self-organization
http://en.wikipedia.org/wiki/Stuart_Kauffman#Work

The science is that convergence to self-organization (aka evolution)
adapts faster the more mutations per generation.  Thus larger populations
are more convergent.  Thus hiding the real holes (thus only a few
mutations per generation can reveal them) is **LESS** secure.  It is the
analogous point made for open source.  Security holes are bugs, we must
reveal them, not obscure them in conflated security castle models.

I am thinking far, far ahead of you.  I am thinking of ramifications of
the castle model and where it ends up, analogous to how I warned before
and was ignored but proven correct:

http://www.ietf.org/mail-archive/web/hybi/current/msg03893.html
(I am not gloating, just at peace with our success)

The bottom line is that the security problem is the injection hole at the
bad protocols or servers.  If you try to fix that by applying filters at a
perimeter defense line, then Coase's Theorem insures that the viruses
(cock roaches over castle walls) will go around you, and the good programs
(guys inside the castle) will loose features (food).

When you conflate the outer perimeter (i.e. the browser sending a request)
with the actual hole (i.e. the bad protocol), then you are in the castle
model with ever higher walls and smaller doors.  It is a model from which
you never escape, it only gets worse and worse, because it can not
mathematically converge to fixes and it can only converge to ever
increasing (higher) barriers to functionality.



> As for turning features on or off, I have no idea what you propose
there. If
> some
> feature needs to be turned on to make legitimate sites work, then users
will
> turn
> it on for every site. If it's made too difficult to turn on then sites
won't
> be able to
> count on it and it will go unused. Extensive HCI research indicates that
users
> simply can't discriminate effectively in these matters.

If we create the HTTP drafton HTTP initially, it doesn't mean the world is
required to implement it.  We can create a TLS spec too, of whatever. If
we design the layers orthogonally as we should, we don't need to be
talking about what protocol we run on top of right now.

My understanding of the mathematical model of the ramifications, is that
we shouldn't be deciding for the users. It is an abomination of nature
where a few guys at the IETF decide for billions of people what their
priorities are. The HCI research apparently proves that the protocols
better fix themselves or die. If we try to conflate an outer perimeter
with an inner vulnerability, what we do is gradually close the web's doors
until one day there will be no light, nothing. It is an extremely serious
problem, but if you don't look far, far ahead then you don't see the
creep. Programmers (and humans in general) are notoriously incapable at
perceiving exponential (proportional rate of) change until it is too late
to do anything about the bad ramifications (because in exponential creep
the nominal change is small until the very end where it accelerates too
fast).