[Top] [All Lists]

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

2009-08-01 02:12:12


I think you mix up HTTP and client-side scripting. HTTP is only a
protocol to send and request data.

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

The problem only exists in the realm of HTTP due to where code actually
executes for interaction.  HTTP is certainly not part of the problem,
but it also cannot be a part of the solution due to the simplicity of
its design.  In the WWW all interactive code executes at the user-agent
software.  This software is written by a stranger to the local user who
has absolutely no ability to verify the integrity of the code until
after it has executed.  The user-agent cannot even control if the code
executes automatically upon rendering of the page except to completely
disable execution of all client-side code.

What is gained by adding intermediate systems?
Intermediate systems offer a point of execution for code that is neither
the local user-agent or the destination.  This means interactive code
can execute completely outside a client user-agent.  This is important
for a couple of reasons:

1) Code is not executing at the client user-agent, so the client user-
agent is free from vulnerabilities associated with the execution of such

2) The server that owns the code is the exact point of execution for
that code.  This forces such an owner to take ownership of security and
integrity of that code for their own self protection.  In the WWW
client-side code can be intentionally harmful because it is owned by a
server that will never execute it.

3) It is an unrealistic expectation that any professional requirements
for evaluation of security, best practices, or efficiency can be
presumed of either the end user or the developer of client-side code.  A
system of standard limitations for code execution must exist at the
application layer in order to ensure that security is not violated by
poor code developement or end-user ignorance.

Technically speaking HTTP is also unidirectional.  HTTP typically
operates with a GET request for a resource on a server and the server
responds with that resource.  Since logic is not capable of being passed
into that GET request HTTP is unidirectional as a result.  The solution
to HTTP unidirectionality is the XMLHttpRequest object.  SMTP is also
unidirectional.  My solution for SMTP is the XMLSmtpPush object.

With your model, how would this be handled?

In your example the code would execute using HTML's onkeyup event.  The
limitation of this model is that event oriented execution is not
allowed.  This is an intentional decision.  Here is how I explained it

I am extremely hesitant to suggest that any event oriented execution
should exist from an email client.  Its a drastic hard stop to
completely remove the possibility of security compromise from the
client.  I believe there is a middle ground where extremely limited
interactions are possible from execution based upon client events, such
as mere manipulation of the DOM.  It is very possible that such limited
execution can be easily specified, but I believe this would be too
easily abused.  I believe people know how things should work on the WWW
and if provided the opportunity would do everything in their power to
ensure that they work in email without regard for the standards or
security compromises.

In this model interaction occurs by result of expected content responses
to a transmission opposed to execution of events.  I simply do not want
to invite the opportunity for abuse if then intent of this model is

I have not examined the transmission model of XMPP, but I really do
enjoy that is written as XML opposed to seven bit ASCII.  I have chosen
SMTP for this model, because SMTP is the most widely supported
communication and it contains the necessary intermediary agents which
HTTP does not.


----- Original Message -----
From: "Peter J. Holzer" <hjp-ietf-smtp(_at_)hjp(_dot_)at>
Date: Saturday, August 1, 2009 2:11
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
To: ietf-smtp(_at_)imc(_dot_)org

[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 
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 
HTTPas 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 
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 
somemerit. 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 
allowcommunication in both directions, while SMTP is unidirectional 
(exceptfor 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 
searchrequest 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?


  _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | hjp(_at_)hjp(_dot_)at         | Named "If you want it -- write it"
__/   | |  -- Ilja O. on 

<Prev in Thread] Current Thread [Next in Thread>