Re: Requesting comments on draft-cheney-safe-02.txt

["Peter J. Holzer" <[e-mail]>]

[can you get your MUA to wrap lines at approximately 70 characters?
Single lines of 750+ characters are a bit unwieldy]

On 2009-07-31 02:36:31 +0400, Cheney, Edward A SSG RES USAR USARC wrote:
> The idea is that security vulnerabilities on the internet occur most
> significantly as a result of client-side scripting from documents
> transmitted across HTTP.  By most significant I mean as measured by
> quantity and not severity.  In addition to frequent immediate
> vulernabilities client-side scripting can also operate as an execution
> point for other additional vulernabilities not directly associated
> with client-side scripting.  It is my opinion that the only way to
> solve this security problem is to either break HTTP or eliminate
> client-side scripting.  I find there is no reason to break HTTP since
> it is working perfectly well and is not to blame for this problem.

I think you mix up HTTP and client-side scripting. HTTP is only a
protocol to send and request data. Some clients interpret some data
received by HTTP as code, but that has nothing to do with the HTTP
protocol itself. The same data received via FTP, or SMTP could be
interpreted just the same.

Therefore I don't think you gain anything by using SMTP instead of HTTP
as the transport protocol.


> Client-side scripting cannot be removed unless an alternative
> convention is proposed.
[...]
> As an alerternative method of allowing interactivity from client-side
> scripting I wrote this document to migrate the concept of client-side
> scripting to the email architecture.  The idea is that interactivity
> from client-side scripting can be replaced by transaction
> interactivity.  Since mail servers are intermediate agents in the
> transmission, opposed to an end point like an HTTP server, they can
> make processing or scripting decisions upon data without that
> scripting having to exist on a client system.

What is gained by adding intermediate systems? I see only added
complexity and a potential for additional security holes here.

The idea to run the scripts on the server and let them only manipulate
the DOM of a document on the client via a well-defined protocol has some
merit. But it probably makes a lot more sense to base this protocol on
HTTP or XMPP than on SMTP. (most importantly, because HTTP and XMPP allow
communication in both directions, while SMTP is unidirectional (except
for status codes))


> In other words, it is basically an inverted form of AJAX that does not
> execute on the client-side.  The idea is easily possible using SMTP,
> but is not possible over HTTP since HTTP does not have intermediate
> agents between the client and server.

I don't see what purpose the intermediate servers serve in your model.
Why are they necessary?

As a sample use case, consider a typical "autofill" search form:

The browser has just loaded an HTML (or other markup language, if you
prefer) page with a search form.

With AJAX, the HTML file contains s script which will intercept each
character the user types into the input field, send (via HTTP) a search
request to the server, and then manipulate the dom to display the search
results in a dropdown menu.

With your model, how would this be handled?

	hp

-- 
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [e-mail]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [e-mail]