RE: corrected - Suggested OPES Requirements for Integrity, Priva cy an

Thank you John. I believe that CDT involvement in policy positioning and
discussion of OPES evolution has value to CDT and OPES as well.

At 06:40 PM 9/29/2001, John Morris wrote:
> At 04:10 PM 9/28/01 -0700, Condry, Michael W wrote:
> > While I am glad that OPES has moved from a NON Acceptable Working Group to an
> > acceptable one; I believe that some of the work cited on the web site from
> > Hillary Orman addresses concerns that are overlooked below.
> I absolutely agree.  I focused on Wayne's posting because it addressed a 
> broader set of issues, but Hillary's work also addresses -- very well -- 
> the integrity and notice issues.
> John
> > > -----Original Message-----
> > > From: John Morris [mailto:jmorris(_at_)cdt(_dot_)org]
> > > Sent: Friday, September 28, 2001 2:57 PM
> > > To: 'ietf-openproxy(_at_)imc(_dot_)org'
> > > Cc: Davidson, Alan
> > > Subject: Re: corrected - Suggested OPES Requirements for Integrity, 
> > > Privacy and Security
> > > I would like to follow up on some concerns I raised last month 
> > > concerning the OPES proposal. I apologize for the time lag; the past few 
> > > weeks have been hectic, to say the least.
> > > I was very impressed by Wayne Carr's posting on "Suggested OPES 
> > > Requirements for Integrity, Privacy and Security" (most recently posted 
> > > in full on Aug. 16, and quoted in full below). Wayne's suggestions 
> > > address many of the specific concerns raised about OPES. Although there 
> > > has not been a huge amount of discussion on the list about Wayne 
> > > proposals, if those suggestions come to represent a consensus of the 
> > > group, then many (but not all) concerns can be resolved. I've also had 
> > > some online and off-line conversations with Michael Condry, and I am 
> > > very encouraged by Michael's and Markus Hofmann's approach to the issues 
> > > raised. All in all, assuming that certain privacy and integrity 
> > > protections can be incorporated into the goals of the working group, 
> > > then I would be supportive of OPES being made into a WG and proceeding 
> > > through the normal IETF processes.
> > > Having said that, I would like to recap the concerns raised by OPES, and 
> > > set out my perception of the best ways to allay the concerns (drawing in 
> > > many instances from Wayne's suggestions):
> > > ** End Point Notice [disclosure of the OPES Intermediary and the OPES 
> > > activity performed must be given to both end points of an exchange] : 
> > > Wayne thoroughly addresses this need in paragraphs 6.1 through 6.5 of 
> > > his suggestions.
> > > ** Consent [the sender or ultimate recipient of a communication (and 
> > > sometimes both) must consent to the OPES transformation]: Again, Wayne 
> > > appears to have covered all of the bases in his paragraphs 3.1 through 3.8.
> > > ** End Point Negotiation and Veto [the sender or recipient should be 
> > > able to veto an OPES transformation requested by the other party to the 
> > > communication, and in some cases the end points should be able to 
> > > negotiate on OPES transformations]: Wayne addresses this concern in 
> > > paragraphs 3.5,3.7,and 4.1 - 4.3
> > > ** End Point Privacy [an OPES intermediary much comply with the privacy 
> > > policy of the content provider, the privacy preferences of the end user 
> > > must be honored the Intermediary]: Wayne addresses this concern in 
> > > paragraphs 5.1 through 5.9. We may need to seek to extend the P3P 
> > > specification to cover OPES transformations.
> > > ** Facilitating Gatekeepers and Bottleneck Power [OPES will permit ISPs 
> > > to contract with "preferred" OPES service providers and thereby reduce 
> > > the opportunity for innovation]: Wayne's suggestions do not address this 
> > > concern, and it remains a serious possibility in light of the strong 
> > > pressure on ISPs to find ways to get revenue. Michael has argued that 
> > > the risk of a bottleneck will exist with proprietary OPES-like services, 
> > > and that standardizing OPES will increase the outlets available to 
> > > developers and thereby encourage more development of OPES services. On 
> > > this point, it does appear that the benefits to standardizing OPES 
> > > outweigh the possibly unavoidable creation of bottlenecks.
> > > ** Facilitating Unauthorized Interference with Content [OPES would 
> > > diminish end to end network design principles and facilitate third-party 
> > > manipulate communications without the notice or consent of end point 
> > > parties]: Taken together, all of Wayne's suggestions mitigate (but do 
> > > not eliminate) the risk that OPES tools can be abused. Tools that permit 
> > > the efficient mid-stream review, altering, or other manipulation of 
> > > content could be greatly abused by censoring governments or overly 
> > > aggressive ISPs. There are a number of steps that could be taken within 
> > > the OPES design documents to reduce (but not eliminate) this risk:
> > >         a. The OPES protocol could require that content providers or 
> > > end users that affirmatively want their content run through an OPES 
> > > transformation MUST include a metatag indicating that intent, and the 
> > > OPES Intermediary MUST look for that tag before performing an OPES 
> > > service (as opposed to, for example, simply looking for a URL that 
> > > matches a rule). By requiring that a proper, conforming implementation 
> > > of OPES must look for a metatag inserted by an end point, the risk is 
> > > reduced that an "off-the-shelf" OPES implementation can be used for 
> > > unauthorized content manipulation or screening.
> > >         b. The OPES protocol documents could include provisions stating 
> > > that OPES implementations MUST NOT permit the notice, consent and 
> > > privacy elements to be turned off or otherwise by-passed except as 
> > > expressly permitted by the protocol documents. In other words, an OPES 
> > > implementation may not make the privacy and security enhancements 
> > > advanced by Wayne Carr optional. By making those provisions mandatory, 
> > > there is a lower risk that an "off-the-shelf" OPES implementation can 
> > > be misused.
> > > These provisions would not make OPES immune to misuse; it will certainly 
> > > still be possible for an OPES implementation to be altered internally to 
> > > (for example) disable the required notice to the end points. But make 
> > > ensuring that a fully conforming implementation of OPES cannot easily be 
> > > misused, I think you will have gone as far as possible to promote proper 
> > > deployments of OPES without creating undue risk.
> > > If the approaches advanced by Wayne and this e-mail prove to be 
> > > acceptable to the group and can be implemented, then I for one would 
> > > support OPES proceeding to WG status and ultimate adoption as an IETF standard.
> > > I do want to respond briefly to some of the frustration voiced in 
> > > response to the raising of these concerns about OPES. If OPES is 
> > > successful in its goal of permitting efficient mid-stream 
> > > transformations of content flowing on the Internet, I think it is 
> > > inevitable that OPES tools will be misused, and misused in ways that no 
> > > one on this list will support. Although addressing the privacy and 
> > > consent concerns at this stage does little to advance the efficient 
> > > engineering of the core functions of OPES, early attention to those 
> > > concerns should greatly help OPES withstand any problems caused by 
> > > future possible misuse of the tools. It is not enough to point out, 
> > > correctly, that there are lots of things on the Internet that can be 
> > > misused, and to complain that OPES is being "picked on." I would hope 
> > > that anything that has the potential for misuse is carefully considered 
> > > as it wends its way through the IETF processes.
> > > In any event, it appears that the OPES effort can address integrity, 
> > > security, privacy, and other concerns at this stage, and by so doing it 
> > > should be able to proceed within the IETF now and be a successful 
> > > protocol in the future.
> > > John Morris
> > > ----------------------------------------
> > > John B. Morris, Jr.
> > > Director, Internet Standards, Technology
> > > & Policy Project
> > > Center for Democracy and Technology
> > > 1634 I Street NW, Suite 1100
> > > Washington, DC 20006
> > > (202) 637-9800
> > > (202) 637-0968 fax
> > > jmorris(_at_)cdt(_dot_)org
> > > http://www.cdt.org
> > > ----------------------------------------
> > > At 9:55 AM -0700 8/16/01, Carr, Wayne wrote:
> > > W. Carr
> > > Intel Corporation
> > > 16 August 2001
> > > Suggested OPES Requirements for Integrity, Privacy and Security
> > > Abstract
> > > Intermediary devices are widely deployed to provide services like caching or
> > > virus checking. OPES is intended to provide a framework to enable pluggable
> > > services in Intermediaries that provide these services.
> > > This framework can also provide greater assurance that Content Provider and
> > > End User expectations about Content Integrity and Privacy are met. This
> > > document proposes a set of Content Integrity, Privacy and Security
> > > requirements for the OPES framework.
> > >
> > > 1. Introduction
> > > Intermediaries are deployed to help scale the WWW or to add additional
> > > services like virus checking. It is important to ensure Intermediaries
> > > provide their benefits while maintaining end to end Integrity and privacy.
> > > Intermediaries should not provide application level services that are not
> > > requested by either the Content Provider or End User. This document
> > > contains a set of suggested requirements for the OPES framework.
> > > This is a preliminary version aimed at stimulating discussion. This is
> > > likely more than is necessary. Some of this may be redundant, may be too
> > > difficult to design or implement, or may require work that would not fall
> > > under OPES (i.e. could be in W3C's domain).
> > > 2. Terminology
> > > OPES Intermediary - An application level web device that is part of a
> > > transaction but is neither the originating or terminating device in a
> > > transaction. In HTTP, this includes proxies, surrogates and other gateways
> > > that are neither End Users or Content Providers
> > > OPES - Open Pluggable Edge Services. OPES is a framework that enables
> > > plugging new services in at Intermediaries. Services are must be authorized
> > > by either Content Provider or End User.
> > > OPES Call Out Service - A service called by an OPES Intermediary to perform
> > > some action on behalf of the Content Provider or End User.
> > > Content Provider - The end points in a transaction that is the originating
> > > source of the Content. It is the end point the End User seeks content from.
> > > End User - The end point in a transaction that requests Content from the
> > > Content Provider.
> > > Content Providers Intermediaries Permissions format - a format used to
> > > describe what activities Intermediaries are permitted to take on behalf of
> > > Content Providers.
> > > End User Intermediaries Permissions format - a format used to describe what
> > > activities Intermediaries are permitted to take on behalf of End Users.
> > > Content Provider Intermediaries Privacy policy format - a format used to
> > > describe privacy requirements aimed at Intermediaries. These requirements
> > > can be more stringent for Intermediaries than end to end W3C P3P privacy
> > > policy for the actions by the Content Provider.
> > > End User Intermediaries Privacy policy format - a format used to describe
> > > privacy requirements aimed at Intermediaries. These requirements can be
> > > more stringent for Intermediaries than end to end W3C P3P privacy policy for
> > > the actions by the Content Provider.
> > >
> > > 3. OPES Content Integrity Requirements
> > > 3.1 OPES Intermediaries must not alter any Content unless expressly
> > > permitted to by the Content Provider or the End User.
> > > 3.2 An extensible Content Providers Intermediaries Permissions format for
> > > use by Content Providers must be defined indicating what parts of content
> > > can be modified and what modifications are allowed. This must allow
> > > different permissions for different resources.
> > > 3.3 A means for OPES Intermediaries to fetch Content Providers
> > > Intermediaries
> > > Permissions documents must be provided. One means must be inclusion of an
> > > OPES
> > > Intermediaries Permissions document at a well-known place on the Web site
> > > (similar to P3P). Another means for providing Content Providers
> > > Intermediaries Permissions must be to provide a Content Providers
> > > Intermediaries Permissions document directly to an Intermediary as part of
> > > authorization of that Intermediary by the Content Provider. The document
> > > delivered in this way must have an expiration date associated with it.
> > > 3.5. If the Content Providers Intermediaries Permissions document requires
> > > identification of Intermediaries in requests, then in the response to OPES
> > > Intermediaries identifying themselves during a request for a resource
> > > (below), a Content Provider must be able to inform an OPES intermediary not
> > > to act on the response.
> > > 3.6. An extensible End User Intermediaries Permissions format for use by End
> > > Users must be defined indicating what types of Intermediary activities they
> > > allow. This must allow different permissions for different requests.
> > > 3.7. A means to pass End User Intermediaries Permissions to OPES
> > > Intermediaries as part of a resource request must be defined.
> > > 3.7. A means for either a Content Provider or End User to indicate
> > > Intermediary activity is limited to passing on the request or response must
> > > be provided.
> > > 3.8 A optional means to digitally sign both Content Provider and End User
> > > Intermediaries Permissions must be provided.
> > > 4. OPES End to End Data Integrity
> > > The following requirements are not aimed at implementations of
> > > Intermediaries. Rather, they enable Content Providers to take action to
> > > allow End User Agents (or others) to check that content has not being
> > > altered by Intermediaries (or by hackers changing the Web site).
> > > 4.1 A format for use at a Web site to associate digital signatures with
> > > parts of content should be designed. This will enable End User agents (or
> > > others) to check content integrity to ensure parts of pages not intended to
> > > be transformed have been left unchanged. W3C Signatures should be used if
> > > practical.
> > > 4.2 A means for creating temporary versions of the integrity check format
> > > for dynamically created content should be possible.
> > > 4.3 A mechanism should be defined to allow End Users (or others) to retrieve
> > > integrity checking information for resources from a Web Site. One mechanism
> > > for retrieving this information is placement at a well-known place on the
> > > Web site (similar to P3P).
> > > 5. OPES Privacy requirements
> > > 5.1 OPES Intermediaries must not violate a Web site's W3C P3P policy
> > > applicable to a resource (P3P policy are found at the Content Providers Web
> > > Site).
> > > 5.2 Both Users and Content Providers must be able to define additional
> > > privacy
> > > requirements that apply to Intermediaries in an Intermediaries Privacy
> > > policy. P3P describes privacy policy end to end, but a more restrictive
> > > privacy policy may be desirable at Intermediaries. The Intermediaries
> > > Privacy Policy must include the ability to specify what information can be
> > > recorded by Intermediaries and how it is used.
> > > 5.3 A mechanism must be established for OPES Intermediaries to access a
> > > Content
> > > Provider's Intermediaries Privacy policy. One method for Content Providers
> > > must be to place an Intermediaries Privacy policy document at a well known
> > > place on their Web site. Another method must be to supply it to the
> > > Intermediary when the Content Provider Authorizes activity by the
> > > Intermediary.
> > > 5.4 A mechanism must be established for OPES Intermediaries to receive an
> > > End User's Intermediaries Privacy policy.
> > > 5.5 OPES Intermediaries must honor both End User and Content Provider
> > > Intermediaries Privacy policies.
> > > 5.6 OPES Intermediaries Privacy policies must be able to specify what
> > > information Intermediaries can or cannot record, including cookies, IP
> > > addresses, HTTP header fields and how they can use that information.
> > > 5.7 OPES Intermediaries Privacy policies must be able to specify what
> > > information can or cannot be passed by OPES Intermediaries to OPES callout
> > > services, including cookies, IP addresses, HTTP header fields.
> > > 5.8 OPES Intermediaries Privacy policies must be able to specify that OPES
> > > Intermediaries must indicate what information has been recorded. This
> > > information must be passed to the Content Provider on requests (if required
> > > by the Content Provider's Intermediary Privacy policy) and must also be
> > > returned to the End User in responses (default, even when no End User
> > > Intermediaries Privacy Policy is available).
> > > 5.9 OPES Intermediaries Privacy policies must be able to specify that OPES
> > > Intermediaries should pass through requests or responses without OPES
> > > callouts.
> > > 6. OPES activity reporting requirements
> > > 6.1 OPES Intermediaries must announce their presence and identity and the
> > > type of activity they perform either on the request or a response in a way
> > > detectable by Content Providers on requests if that is required in the
> > > Content Providers Intermediaries Permissions document. This requirement
> > > must not limit the ability to use cached resources that are still valid.
> > > 6.2 OPES Intermediaries must announce their presence and identity and the
> > > activity they performed in a way detectable by End Users on responses unless
> > > waived in End User Intermediaries Permissions.
> > > 6.3 OPES Intermediaries must provide notification to a Content Provider that
> > > a request has been changed if that is required in the Content Providers
> > > Intermediaries Permissions. This notification must include the identity of
> > > the OPES intermediary and what information was altered (header fields,
> > > etc.). The OPES Intermediaries must ensure this information is also included
> > > in the response back to the End User unless the End User Intermediaries
> > > Permissions waives this requirement.
> > > 6.4 OPES Intermediaries must provide notification to the End User that a
> > > response has been changed. This notification must include the identity of
> > > the OPES intermediary and what information was altered (header fields, etc.)
> > > unless the End User Intermediaries Permissions waives this requirement.
> > > 6.5 OPES Intermediaries must provide notification to the End User that a
> > > response has been filtered to look for particular contents. An indication
> > > must be included that can be used to determine what kind of filtering was
> > > applied in examining content. This could be an URL pointing to a Web page
> > > that describes what the filter looks for. The End User Intermediaries
> > > Permissions must provide a way for the End User to waive this requirement.
> > > 7. OPES Intermediaries management security requirements
> > > 7.1 There is no requirement to specify how to add or remove an OPES
> > > Intermediary device into the data path. That is determined by OPES product
> > > vendors and their customers.
> > > 7.2 A format must be provided to add or remove an OPES callout service in an
> > > OPES Intermediary. This format must include a means to digitally sign the
> > > request. The format must allow inclusion of OPES Intermediary vendor
> > > specific information (that could be necessary for authorization).
> > > 7.3 The format for adding services must be able to require a particular
> > > means of secure transmission of data between OPES intermediary and a callout
> > > service.
> > > 7.4 OPES product vendors can create their own, possibly proprietary,
> > > mechanisms for how to use the service add/remove format to add new services
> > > to an OPES Intermediary. OPES product vendors also determine how they use
> > > the digital signature in the service add/remove format. There is no
> > > requirement for the initial version of OPES to specify a standard mechanism
> > > for automating adding or removing a callout service in an OPES Intermediary.
> > > 7.5 A format must be provided for creating or modifying rules that determine
> > > when callout services are invoked by an Intermediary. Callout services must
> > > never be invoked without this authorization. This format must include a
> > > means to digitally sign the request. This format when used by Content
> > > Providers must include a way to include their OPES Intermediaries
> > > Permissions and OPES Privacy Documents.
> > > 7.6 OPES product vendors can create their own mechanisms for specifying what
> > > signatures will be considered authorized for adding or modifying rules for
> > > service invocation. OPES product vendors determine how they use the digital
> > > signature in the service rules modification format. There is no requirement
> > > for the initial version of OPES to specify a standard mechanism.
> > Michael W. Condry
> > Director,  Network Edge Technology