Re: Requesting comments on draft-cheney-safe-02.txt
"Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil> Sat, 08 August 2009 20:59 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 n78KxLRH073149 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 8 Aug 2009 13:59:21 -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 n78KxL2u073148; Sat, 8 Aug 2009 13:59:21 -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 n78KxEmv073140 for <ietf-smtp@imc.org>; Sat, 8 Aug 2009 13:59:20 -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=UGuvNSvJkgpzXdsRh5WMjhW4bzfHQgTuOoJ29n110YTSEWP8rGWaGVcs fo9+vQkaSMmt/RWAA/H/CrbHxOWipg==;
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=1249765160; x=1281301160; 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:=20Sun ,=2009=20Aug=202009=2000:59:14=20+0400|Message-ID:=20<f77 ca8111ab99.4a7e1f62@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<4A7D9E 48.4010201@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>; bh=/4is4ZembpZ87jJiftfokLNlsdj18KdShDK3Zfz7/Lc=; b=UGvNXVmgOyv1Zc/80Rfi7zJq75ncDVNa4kzQThCOmSIq54Cd88wzGd1p UjvkUNJaf0JMxBkKYrEtdFbLdZP6KKfcwc/X13mKZG5sAhml2U+x4t3cQ wfsvdJRG2EN+YFI2UJeaiC20lcqM3L5/lmcI3hgGrit3VV7Nw5juaRJRB 4=;
From: "Cheney, Edward A SSG RES USAR USARC" <austin.cheney@us.army.mil>
X-AKO: 101160542:10.224.29.21:08 Aug 2009 20:59:14 +0000:$Webmail:None
X-IronPort-AV: E=Sophos;i="4.43,347,1246838400"; d="scan'208";a="101160542"
Received: from lb2pip21.int.ps1.us.army.mil (HELO us.army.mil) ([10.224.29.21]) by mxoutps1.us.army.mil with ESMTP; 08 Aug 2009 20:59:14 +0000
Received: from [10.224.32.177] (Forwarded-For: 125.213.207.16, [10.224.32.177]) by mail15.int.ps1.us.army.mil (mshttpd); Sun, 09 Aug 2009 00:59:14 +0400
To: Hector Santos <hsantos@santronics.com>
Cc: Rich Kulawiec <rsk@gsp.org>, ietf-smtp@imc.org
Message-ID: <f77ca8111ab99.4a7e1f62@us.army.mil>
Date: Sun, 09 Aug 2009 00:59:14 +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: <4A7D9E48.4010201@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>
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, Before I begin I want to say any remarks or opinions towards or about commercial media plugin software is entirely personal and hypothetical. Issues associated with such software, even issues of a security nature, are issues respective of a markup language, or other containing feature. The impacts and concerns of such software is not related to or relevant to the SAFE method until communication from such software perform in a manner that violates the privacy inherently presumed of email. At such a point such concerns become a matter of civil liability associated with unsatisfactory disclosure of private communications. > But what about market forces? You must be more specific. Are you suggesting negative impacts to a commercial market will drive users to take more efforts to protect themselves from vulnerabilities associated with technology? If so, I am not aware of any such research, and generally security vulnerabilities tend to dramatically increase during down economies. > All of these players (including Apple, Google, AT&T, ComCast and so > on) have a major strategy to add MORE background communications in > their designs to "network" users and also build their BI for added > value services (direct marketing, social networking). We must remember media plugins of the type you list are created entirely for the web. The web is inherently public as a medium of communication while email is inherently private. This alone would present some minor alterations to product strategy and deployment for such software in order negate civil suits regarding breaches of privacy in email, where such privacy concerns are significantly diminished on the web. The extremely positive thing about proprietary media plugins is that they are managed commercial software. This means the owner of such software is responsible for owning maintenance upon the software, which includes security patches. While this does nothing to protect a user from zero-day exploits, it does however provide a means by which a security resolution to a specific application flaw that is rapidly produced and distributed. Because the owner of the proprietary software is potentially liable for harms inflicted by their software, where those harms not an expectation of user interaction or execution, dire commercial motive exists to ensure the software vendors resolve publicized vulnerabilities as rapidly as possible. > I know of only of WMP and Flash having domain whitelist for cross > domains xtalk. Since email is inherently private the content of a media plugin MUST never communicate to a third party, even if that third party is the software vendor owning the plugin. Since email is inherently private both parties must consent to the release of communications to the public realm before such release deemed appropriate for automated consideration. It is potentially possible there could be some legal remedies to prematurely escape the requirement of dual publication authorization, but I will presume from a standards perspective that such remedies do not and may not ever exist. I, however, do not have a problem with media plugin software beaconing out to its owner when that communication is entirely content independent and does not report any information that can be regarded as private or publicly identifiable information. If a plugin software wishes to report anonymous usage statistics to its owner such communication MUST be communicated to the end user and agreed upon by that end user prior to installation. The plugin software MUST communicate, to the user, all domains it will communicate to prior to installation. > Do you realize we have a 15 year old that is among the decision > makers in how FireFox and Javascript is evolving? Since Firefox is a proprietary software. By proprietary software I mean that it is owned by even if it is licensed as open source. Owners are free to make what ever strategy decisions they wish upon their software products. Owners of software, even if that software is open source, are still liable for harms and exploitations that occur as a result of that software. In other words there is nothing to prevent Mozilla from being named in a law suit than Microsoft for product violations or irresponsible executive decisions. By the way, JQuery founder and developer lead, John Resig, is 25. JQuery is a framework of JavaScript, and so it must be considered no less flawed than JavaScript from a security and deployment consideration. > What I have trouble seeing is how SMTP will help. The objective is to remove client-side scripting from a client-side user-agent regardless of that user-agent being associated with email or the web. The simple answer is to simply turn off all JavaScript, ActiveX, and so forth from all versions of all browsers permanently. That is an impossible decision for the web completely reliate upon client-side scripting. An alternative must exist before reliance upon client-side scripting from the web can be scaled back or eliminated. The SAFE Scripting Method is an attempt to provide a degree of interaction and processing to communications before that communication is received by its intended destination and without that interaction executing at a user-agent. In my opinion people, generally, do not take security seriously. Asking people to turn off client-side scripting on their own accord is not acceptable since the end user cannot be expected to be aware of the impacts of technology decisions. The software vendors are not willing to reduce or exclude client-side scripting in any manner significant enough to even reduce the accelerating growth rate of associated vulnerabilities, because the value of market share is limited to a few software vendors even if the negative impacts associated with that software are a cost burden to us all. As far as I am aware nobody else has presented an interactive solution to the harms of client-side scripting and nobody else has presented a non-proprietary alternative. That does not mean my attempt at such an alternative is without points of disagreement or limitation, but it is substantially more secure than anything else so far proposed. Since this is the only suggestion to cure, opposed to mitigate, the problem it is worthy of consideration unless its proposed technology is flawed or ineffective to its intended objective. > - Some authorization protocol using SMTP (i think), that > is coupled with, > > - Prohibition of existing Interactive methods, i.e. DOM > events. > > I don't see how the two is related or why DOM events can no longer be > used. The second point that you mentioned is the solution to the problem. The first point is an alternative to the elimination of concept represented by the second point. A standard is only retains value if it is adhered to by its concerned parties. My fear in allowing execution of events at the user-agent is that you are only the smallest step away from allowing all forms of execution. I believe that if a hard and fast limitation is not set that first users and then software vendors will make every possible attempt to allow as much interactivity as possible locally with exception to constraints upon transmission. At that point the standard has absolutely no value and Email because just as vulnerable, if not more, than the web. At this moment email is pristine and pure from many of the problems associated with the web, and I don't want to be the one violate that sanctity. > You are not going to stop DOM events, or even get people to consider > not using it. So if that is a major part of SAFE, you already have a > major road block in getting people interested in SAFE. I disagree. From solely a business perspective security mitigation is expensive. I believe if an alternative to such problems does exist that there would be support for adoption from large organizations to curtail security associated expenditures. Large volume organizations direct the strategic course of software development more any other single markup force. One of my employers is the United States military, which is one of the largest employers on the planet. I have seen how all sizes of software vendors have completely revised altered their product strategies to prevent loss of contracts from this single client. There are other single clients that carry almost as much market clout as well. If only a very small few of such parties can be convinced to adopt this methodology the path for adoption is set with a potential for adoption growth. > Never mind the technical issues related to a SMTP callback system > especially one that will be based on HTTP huge redundancy in HTTP > requests. I did not understand this final statement. Could you please clarify this for me? The SAFE model is based solely upon SMTP and references no features of HTTP. Thank you, 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