Re: Requesting comments on draft-cheney-safe-02.txt
"Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil> Wed, 12 August 2009 05:47 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 n7C5lxBd067265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Aug 2009 22:47: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 n7C5lxof067264; Tue, 11 Aug 2009 22:47: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 n7C5llOf067248 for <ietf-smtp@imc.org>; Tue, 11 Aug 2009 22:47:57 -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=t0lBTDnSbY9vdTUvjoCs93Ep/Z7nUggAzNQF9wAjR4xaIhsZ6R4WHiBx g3jZ0/NSqDzy2jep+ikOief1fsd2BQ==;
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=1250056077; x=1281592077; 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:=20Wed ,=2012=20Aug=202009=2009:47:45=20+0400|Message-ID:=20<fc7 aaeea24a1c.4a828fc1@us.army.mil>|To:=20Hector=20Santos=20 <hsantos@santronics.com>|Cc:=20Rich=20Kulawiec=20<rsk@gsp .org>,ietf-smtp@imc.org|MIME-Version:=201.0 |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<4A7E37 DE.7080106@santronics.com>|References:=20<f6fecbd18af7.4a 721c99@us.army.mil>=0D=0A=20<4A720D35.1000306@cybernothin g.org>=0D=0A=20<f6e091e580a6.4a7258af@us.army.mil>=20<200 90807100147.GA16131@gsp.org>=0D=0A=20<f73e99651b6bb.4a7d3 869@us.army.mil>=20<4A7D9E48.4010201@santronics.com>=0D =0A=20<f77ca8111ab99.4a7e1f62@us.army.mil>=20<4A7E37DE.70 80106@santronics.com>; bh=dV3/SGvZlxphHugcWTUIXoRB0eDvGs22WHaXyQpJs5Y=; b=ODp3MvoWcVNrda0yerVkLpyev7vrwWB7GPU70uo74gqG7a2Ro422K+OY uRhBtcVmytRzkzk7baj5geW+/XBgn6maa4xcL1Y1UDiKZ3Cb587TS5Vv3 NKlwcVsvNMl4qF0CeLMOYBtHhtj6fzvxjWEzRhI7Gc76UlyUuWPGZKBn6 s=;
From: "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil>
X-AKO: 102607419:10.224.29.21:12 Aug 2009 05:47:45 +0000:$Webmail:None
X-IronPort-AV: E=Sophos;i="4.43,365,1246838400"; d="scan'208";a="102607419"
Received: from lb2pip21.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.29.21]) by mxoutps1.us.army.mil with ESMTP; 12 Aug 2009 05:47:45 +0000
Received: from [10.101.32.171] (Forwarded-For: 214.13.1.73, [10.101.32.171]) by mail15.int.ps1.us.army.mil (mshttpd); Wed, 12 Aug 2009 09:47:45 +0400
To: Hector Santos <hsantos@santronics.com>
Cc: Rich Kulawiec <rsk@gsp.org>, ietf-smtp@imc.org
Message-ID: <fc7aaeea24a1c.4a828fc1@us.army.mil>
Date: Wed, 12 Aug 2009 09:47:45 +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: <4A7E37DE.7080106@santronics.com>
References: <f6fecbd18af7.4a721c99@us.army.mil> <4A720D35.1000306@cybernothing.org> <f6e091e580a6.4a7258af@us.army.mil> <20090807100147.GA16131@gsp.org> <f73e99651b6bb.4a7d3869@us.army.mil> <4A7D9E48.4010201@santronics.com> <f77ca8111ab99.4a7e1f62@us.army.mil> <4A7E37DE.7080106@santronics.com>
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>
Hector, > Honestly I have been confused with your usage of the term "email." When I use the term email I am describing SMTP protocol reliant data intended for consumption by humans that has an end point at a destination specified by an email address. Since this proposition is inherently SMTP focused I do not see how it could be applied to a radically different protocol, such as HTTP. > You honestly think the javascript 'prototype" API authors are going to > get an act of conscious and ponder "You know, what I am doing is bad?" > or the implementators are going to forgot using these methods? No, I don't, which is all the more motivation to adopt this proposition. >From a security perspective the web is a failure. That should be more reason, and not less reason, to support this attempt at providing a secure alternative. Please read these white papers to see how much of a failure it is and why an alternative to client-side scripting is the only acceptable solution: Symantec Internet Security Threat Report - Trends 2008 http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_internet_security_threat_report_xiv_04-2009.en-us.pdf Symantec - Web Based Attacks http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_web_based_attacks_03-2009.en-us.pdf In considertaion for how Symantec describes the method and deployment of malware infections unto user's computers from legitimate websites it is evident there is no secure form of client-side scripting if the legitimate website cannot be trusted. > We are a CCR contractor (and the feds use we what we have, its > flexible) and in the past, was a military (sub) contractor and yuo kow > what is done for the feds can be much different (requirements) than > what was done for commercialization. Apples and Oranges really. The disparity here is in the cost of alteration versus the quantity of deployment. Costs to provide disparite systems to the government vary significantly with regards to total quantity of the products produced by the vender in ratio to the total commerical products. For something as minor as an enhanced security footprint in Microsoft Windows' registry versus the number of licenses sold to the military it might be cheaper for Microsoft to make the change universal than to provide an alternate form of product licensing for such a significant number of licenses. For a subcontract that produces cutting edge materials in the assembly of a Navy submarine's nuclear reactor the model of business would vary drastically, because of the uniquness of the product and the scarce quantity of total products produced. > I'm just giving my opinion - prohibiting DOM events is a major show > stopper. The current state of security failure on the web is a bigger show stopper. After reading the mentioned whitepapers about how easy it is to steal bank account information from the user, not the bank, accessing a legitamite bank website I cannot possibly see how executive of events bears a greater commercial value to either business of the end user. In 2008 the average cost per breach incident in the US was $6.7 million with an additional $4.6 million in lost revenue. So a single breach incident on a legitimate commerical website that intends to active code on a user machine costs the business $11.3 million. How much more than that can event execution possibly be worth to a business? > People won't bother to read past the abstract or the first > few pages (Why Bother?). Because the web is a security failure and security is expensive. The internet is not free and there is a cost to doing business. How expesive must that cost become before failure results? > But the trend is more WEB 2.0+ and you are seeing sites that won't a) > function and display a notice or b) don't care to explain why its not > working. That is only partially true. It is true that many websites, including my primary employer Travelocity, is entirely reliance upon client-side scripting. To email however client-side scripting has never been considered and does not exist. People will not miss what they never had. By implementing this proposal a foundation exists by which online applications exist in an entirely different model than previously conceived. Since this is a new face to online applications there will be new and completely different expectations of what an application should be and should not be. This difference will influence the characteristics of development in a fashion that does not miss client-side scripting if it is never a capability in the first place. That will provide a point of transition for business migrate from existing methods towards something like interactive email. > Using parato's principle, 80% of the user market, today, won't have a > clue about any of this. At this moment I am not concerned about the understandability of the current market. I am only concerned with the understandability of persons reading the ietf-smtp mailing list. If this can become an RFC it will bear the credibility that will encourage people to understand this proposition. > I said that because you are seeing very popular sites not function at > all without javascript. I am also seeing a rising problem that limits or prevents business. A problem that has no other solution. It is more important to a business that they continue to sell products online than requiring those sells come from a website that is easily open to compromise. > I doubt they are going to alter their strategy for SAFE "Prohibitive > NO-DOM Policy Mandates." They will be economically motivated if they cannot otherwise not afford to continue doing business on the web. > So nothing else matters. The cost of doing business and the cost providing the internet as a service are all that matter in this case. If the web fails then internet standards fail, because this is a technology problem and not a problem of carelessness. > But considering SMTP, I think overall, what you are asking would be > including a "major revamp" In hardware and bandwidth, yes. In protocol support no. This proposition is an entirely unobtrusive plugin to the SMTP protocol. It requires the use of a markup language, which is only a user-agent and not a protocol concern. If a markup language for email is not present then SAFE is completely ignored. As far a SMTP server the new software enhancements would operate much like how PHP operates with Apache. Apache does not care that PHP is installed. Likewise SMTP services direct and respond to traffic completely without care that something else on the same box is modifing that traffic. As a result SAFE would not impact SMTP server services. A bigger impact to those SMTP services would result in adapting the requirements of a markup language header that would very likely compete with or obsolete RFC 5322 header definitions. > In short, SMTP is not an optimal prootocol for this need. SMTP is the ideal protocol for this need. It is robust, bidirectional, universally supported, and perhaps the most adopted communications medium in all history. SMTP has sufficient capabilities to exceed the requests of this proposal. > Maybe I say that because I can not AVOID the idea the DOM is > prohibitive. This proposal actively supports manipulation of the DOM at the user-agent and even provides new capabilities to accomplish such. It only prevents execution of programmatic decisions from within a communication or referenced by a communication. Just out of curiousity how much is event oriented execution worth to you? Is it worth $11.3 million US per breach indicident? Perhaps that is an acceptable cost of doing business, but if so how would you account for those loses? Would you raise prices on the end user, liquify the value of your product, or simply take a smaller pay check? Each of those sound horribly more distateful than considering a newer and fresher way of doing business. Thanks, Austin
- 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