RE: corrected - Suggested OPES Requirements for Integrity, Priva cy and Security
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.
From: John Morris [mailto:jmorris(_at_)cdt(_dot_)org]
Sent: Friday, September 28, 2001 2:57 PM
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
** 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
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
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 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-0968 fax
At 9:55 AM -0700 8/16/01, Carr, Wayne wrote:
16 August 2001
Suggested OPES Requirements for Integrity, Privacy and Security
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.
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).
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 Providers Intermediaries Permissions format - a format used to
describe what activities Intermediaries are permitted to take on behalf of
End User Intermediaries Permissions format - a format used to describe what
activities Intermediaries are permitted to take on behalf of End Users.
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.
privacy requirements aimed at Intermediaries. These requirements can be
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
Permissions documents must be provided. One means must be inclusion of an
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
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
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
5.2 Both Users and Content Providers must be able to define additional
requirements that apply to Intermediaries in an Intermediaries Privacy
recorded by Intermediaries and how it is used.
5.3 A mechanism must be established for OPES Intermediaries to access a
place on their Web site. Another method must be to supply it to the
Intermediary when the Content Provider Authorizes activity by the
5.4 A mechanism must be established for OPES Intermediaries to receive an
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
returned to the End User in responses (default, even when no End User
5.9 OPES Intermediaries Privacy policies must be able to specify that OPES
Intermediaries should pass through requests or responses without OPES
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
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.
|<Prev in Thread]
||[Next in Thread>|
- RE: corrected - Suggested OPES Requirements for Integrity, Priva cy and Security,
John Morris <=