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.
-----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.