Subject: RE: WG Review: Open Pluggable Edge Services (opes)

From: "Abbie Barbir" <[email-masked]>
Date: Wed, 20 Jun 2001 15:45:54 -0400

Well,

The discussion has been interesting so far. It seems to me that a 
compromise can be reached if appropriate hooks are put in place to do the 
following:

1. Ensure that both end points are involved in the decision process.
2. Ensure that OPES's type devices does not allow unauthorized interception 
   of traffic between source and destination.
    - Make it explict that IETF does not endorse any illegal 
      interception/modification/etc of data/content.

Here, I am trying to provide a summary of the points of agreement that have
emerged from the list.

abbie

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 2:39 PM
> To: Joseph Hui
> Cc: [email-masked]; Keith Moore; Barbir, Abbie 
> [CAR:CC70:EXCH];
> Paul Hoffman / IMC; [email-masked]; [email-masked]; Michael W.
> Condry
> Subject: Re: WG Review: Open Pluggable Edge Services (opes)
> 
> 
> > The man-in-the-middle thing can happen irrespective of what 
> OPES does
> > or doesn't do, in the absence of end-to-end security, say TLS.
> > I fail to see how OPES's charter and its 
> yet-to-be-developed protocol
> > would worsen the existing situation.
> 
> - if the interfaces designed by OPES make it easier for intermediaries
>   to process traffic with the authorization of the edges, they might 
>   also make it easier for intermediaries to do so without such 
>   authorization.  however, with appropriate design, it may be 
> possible 
>   to discourage use of OPES without consent of an endpoint.
>   (it wouldn't discourage modification of content by other means, but 
>   at least OPES wouldn't serve to encourage such modification)
> 
> - appropriate clarification of OPES's charter would discourage those
>   who want to develop tools for unauthorized modification, from
>   trying to further those aims within the context of OPES.
> 
> - appropriate restriction on OPES's charter would explicitly forbid
>   OPES from providiing explcit support for unauthorized interception 
>   of traffic that are not needed when authorization is present.
> 
> - appropriate restrictions on OPES's charter, along with language
>   included in any documents that OPES produces, would make it clear
>   that IETF does not endorse unauthorized interception and alteration
>   of network traffic.
> 
> Keith
>

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 15:53:02 -0400

>    of traffic between source and destination.

How would you do either of these?  If the OPES box is allowed to do its
work at all, I don't think either of these is enforceable.

---

From: "James Binder" <[email-masked]>
Date: Wed, 20 Jun 2001 13:41:50 -0700

In essence, I think you would need two channels (bound together somehow) --
One with non-mutable content (i.e., what the user is buying from the origin
server) and mutable content (local site specific ads or what not).

/jsb

---

From: "Scott Brim" <[email-masked]>
Date: Wed, 20 Jun 2001 22:07:27 -0400

I think you could do most of this with signatures.  You can make sure
that if someone does modify the original, you know about it, and that
means you can make sure only someone you've authorized can modify the
material.  However in the case where an intermediary is supposed to
replace material for you (e.g. change encoding for a low bandwidth
device), you can't be sure that what eventually arrives has any relation
to what was originally sent.

...Scott

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 21 Jun 2001 10:10:30 -0400

There seems to be consensus that OPES services would have to be
authorized explicitly and must not be transparent to both end-points.
This is in line with the discussion we had at the OPES BOF in
Minneapolis and is also reflected in the group description on the web
page ("Intermediary services provided in this way are not transparent:
They have to be authorized by either the content requester or the
provider, corresponding to who the service being provided for"). Looks
like this should be made explicit in a charter.

However, it's not yet clear whether we've consensus that such services
have to be authorized by BOTH or by EITHER ONE of the end-points.
There certainly are services that have to be authorized by both sides.
But it seems there are also services that can be authorized by only
one of the end-points.

Services that basically extend the origin web server, such as dynamic
assembling of pages on behalf of the content provider, probably do NOT
have to be authorized by the user.

What about, for example, a service that does NOT modify the content
itself (i.e. the response), but modifies the request and is executed
on behalf of and with permission of the user (e.g. to replace cookies,
make the request anonymous,...)? Seems like the content provider would
not have to give permission for such services.

Comments? Possible to reach consensus on this one?

-Markus

---

From: "James Binder" <[email-masked]>
Date: Thu, 21 Jun 2001 09:11:37 -0700

Agreed.  Transcoding would be an issue.

/jsb

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, June 20, 2001 7:07 PM
To: [email-masked]; [email-masked]
Subject: RE: WG Review: Open Pluggable Edge Services (opes)

...Scott

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Jun 2001 13:28:55 -0400

offhand, I haven't thought of a service for which the consent of
both parties should be required.

---

From: [email-masked]
Date: Thu, 21 Jun 2001 11:33:25 -0700 (PDT)

> both parties should be required.

A data escrow facility would seen to be an example of such a service.

But even if examples of this are hard to come by, I don't think it would
justify not including the ability to obtain consent from both parties in the
model. We're quite bad at predicting the full generality of useful (and legal,
and morally defensible) applications that develop over time.

				Ned