Re: Requesting comments on draft-cheney-safe-02.txt
"Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil> Sat, 01 August 2009 05:56 UTC
Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n715ux7v032662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 Jul 2009 22:56:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n715uxFs032661; Fri, 31 Jul 2009 22:56:59 -0700 (MST) (envelope-from owner-ietf-smtp@mail.imc.org)
X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-smtp@mail.imc.org using -f
Received: from mxoutps1.us.army.mil (mxoutps1.us.army.mil [143.69.250.38]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n715uv6T032638 for <ietf-smtp@imc.org>; Fri, 31 Jul 2009 22:56:58 -0700 (MST) (envelope-from austin.cheney@us.army.mil)
DomainKey-Signature: s=ako; d=us.army.mil; c=nofws; q=dns; h=From:X-AKO:X-IronPort-AV:Received:Received:To:Cc: Message-ID:Date:X-Mailer:MIME-Version:Content-Language: Subject:X-Accept-Language:Priority:In-Reply-To:References: Content-Type:Content-Disposition: Content-Transfer-Encoding; b=bMlSp768FkgFjOAurWgz4EJIaT2ILk+hYkQ83kjF3Ob3jUh18tNH5ryf IZzC035HaiNHjGRk5qN5ei9ndGWacQ==;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=us.army.mil; i=austin.cheney@us.army.mil; q=dns/txt; s=akodkim; t=1249106218; x=1280642218; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20"Cheney,=20Edward=20A=20SSG=20RES=20USAR=20USARC "=20<austin.cheney@us.army.mil>|Subject:=20Re:=20Requesti ng=20comments=20on=20draft-cheney-safe-02.txt|Date:=20Sat ,=2001=20Aug=202009=2009:56:55=20+0400|Message-ID:=20<f71 b8961c81e.4a741167@us.army.mil>|To:=20"Peter=20J.=20Holze r"=20<hjp-ietf-smtp@hjp.at>|Cc:=20ietf-smtp@imc.org |MIME-Version:=201.0|Content-Transfer-Encoding:=207bit |In-Reply-To:=20<20090731211500.GA18426@hjp.at> |References:=20<f6fecbd18af7.4a721c99@us.army.mil>=0D=0A =20<4A720D35.1000306@cybernothing.org>=0D=0A=20<f6e091e58 0a6.4a7258af@us.army.mil>=20<20090731211500.GA18426@hjp.a t>; bh=96OOrd54levKzb3xE3tBhDZNvVFFDyZM6xBvFOeZVPc=; b=ZGtbuBgMZwzrnIsREpfVlM5unjgISYzJqSQhcmT4z0PtbJG/1XlRfmtv VJdmFiMaYy9PRTM3NZI4dBD7vFhdkS7Tp258NdfboGUcFl2/ETL/1BiBk Bv10GnDrLRyXc+IVCfsFnqOZ6D5SikOMKfWH8I78SQW+7dyJbO6SdU1uc s=;
From: "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil>
X-AKO: 97136923:10.224.29.21:01 Aug 2009 05:56:56 +0000:$Webmail:None
X-IronPort-AV: E=Sophos;i="4.43,306,1246838400"; d="scan'208";a="97136923"
Received: from lb2pip21.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.29.21]) by mxoutps1.us.army.mil with ESMTP; 01 Aug 2009 05:56:56 +0000
Received: from [10.101.32.172] (Forwarded-For: 214.13.1.64, [10.101.32.172]) by mail15.int.ps1.us.army.mil (mshttpd); Sat, 01 Aug 2009 09:56:55 +0400
To: "Peter J. Holzer" <hjp-ietf-smtp@hjp.at>
Cc: ietf-smtp@imc.org
Message-ID: <f71b8961c81e.4a741167@us.army.mil>
Date: Sat, 01 Aug 2009 09:56:55 +0400
X-Mailer: Sun Java(tm) System Messenger Express 6.3-6.03 (built Mar 14 2008; 32bit)
MIME-Version: 1.0
Content-Language: en
Subject: Re: Requesting comments on draft-cheney-safe-02.txt
X-Accept-Language: en
In-Reply-To: <20090731211500.GA18426@hjp.at>
References: <f6fecbd18af7.4a721c99@us.army.mil> <4A720D35.1000306@cybernothing.org> <f6e091e580a6.4a7258af@us.army.mil> <20090731211500.GA18426@hjp.at>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smtp@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smtp/mail-archive/>
List-ID: <ietf-smtp.imc.org>
List-Unsubscribe: <mailto:ietf-smtp-request@imc.org?body=unsubscribe>
Peter, > 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 code. 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 yesterday: 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 security. 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. Thanks, Austin ----- Original Message ----- From: "Peter J. Holzer" <hjp-ietf-smtp@hjp.at> Date: Saturday, August 1, 2009 2:11 Subject: Re: Requesting comments on draft-cheney-safe-02.txt To: ietf-smtp@imc.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 > 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 > 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 > 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 > 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? > > hp > > -- > _ | Peter J. Holzer | Openmoko has already embedded > |_|_) | Sysadmin WSR | voting system. > | | | hjp@hjp.at | Named "If you want it -- write it" > __/ | http://www.hjp.at/ | -- Ilja O. on > community@lists.openmoko.org
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Peter J. Holzer
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Alessandro Vesely
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… J.D. Falk
- Requesting comments on draft-cheney-safe-02.txt Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Rich Kulawiec
- Re: Requesting comments on draft-cheney-safe-02.t… Rich Kulawiec
- Re: Requesting comments on draft-cheney-safe-02.t… Rich Kulawiec
- Re: Requesting comments on draft-cheney-safe-02.t… Steve Atkins
- Re: Requesting comments on draft-cheney-safe-02.t… Dave CROCKER
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: [AKO Warning - Message fails DKIM verificatio… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… John C Klensin
- Re: [AKO Warning - Message fails DKIM verificatio… Cheney, Edward A SSG RES USAR USARC
- Re: [AKO Warning - Message fails DKIM verificatio… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… John R Levine
- Re: [AKO Warning - Message fails DKIM verificatio… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Willie Gillespie
- Re: [AKO Warning - Message fails DKIM verificatio… John Levine
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: [AKO Warning - Message fails DKIM verificatio… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… J.D. Falk
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… John C Klensin
- Re: Requesting comments on draft-cheney-safe-02.t… Rich Kulawiec
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Robert A. Rosenberg
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Willie Gillespie
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Peter J. Holzer
- Re: Requesting comments on draft-cheney-safe-02.t… Steve Atkins
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Cheney, Edward A SSG RES USAR USARC
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… Hector Santos
- Re: Requesting comments on draft-cheney-safe-02.t… SM