Subject: opes and technology picks

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2001 20:40:53 -0700

>By appearing to make it legitimate (as RFC 1918 made NAT appear
>legitimate). There is a possible way to deal with this though: require an
>OPES box to obtain explicit consent from both ends before executing
>any content manipulation. 
>
>   Brian
>
Why is it not acceptable to have one host or its owner approve of such a 
use?  Consider a web farm.  How do we decide whether such "legitimate" 
uses will be outweighed by "illegitimate" uses?

Eliot

---

From: [email-masked]
Date: Thu, 21 Jun 2001 00:22:21 -0400

> uses will be outweighed by "illegitimate" uses?

Actually, even having *both* ends approve first is problematic.  Consider
that current browsers do a *LOT* of things "under the hood" that users
may not know about - and a certain large vendor of browsers recently
announced a "feature" to add links at time of display to the user.

The threat model there is that the browser could be adding what appear
to be links to a competitor's web page. (And yes, I know all the stuff
about adding a META tag to tell it to cut it out - but why should I as
(for example) the web designer for Ford Motor Company have to go through
*every single* webpage and add a "dont add any <censored>ing links to
Chevrolet" tag?

Now, somebody want to tell me why said vendor of browsers won't feel
an urge to add code that says "Even if Ford said no links to Chevy,
tell the OPAS upstream to stick a link to Chevy in so the browser can
feel smug and morally correct in not having added the link itself"?

And yes, based on past behavior, I *do* think this is a credible
threat model.  Unfortunately, this has 2 problems:

1) I have no idea how to codify a requirement that permission be
given by the content provider at the source end (which can be automated)
and require *user* approval at the sink end (*NOT* automated).

2) This would effectively screw any attempts to use this for
EDI or other B2B automated systems.  This may be considered by
some to be a feature, not a bug.....

/Valdis

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2001 22:04:59 -0700 (PDT)

Valdis,

The battle you are attempting to fight is quite different from the risk of
OPES.  I don't think we will ever save the users from evil (or more likely
stupid) code, be it in the products of certain large vendors, or in
freeware. My concern with OPES would be a modifying of data in a way that
neither end could determine.  I am not willing to protect the end points
from themselves. Nor can I. 

Mo's warning is quite reasonable-- there is a limit to what goo you should
put in the middle, but I question the meaning of an end point.  If we
allow for the notion of things like web farms, can we not also allow for
some set of standards that support such things?  I think so.  However, I
can't say that's what OPES will do because the charter is too vague.

Eliot

---

From: [email-masked]
Date: Thu, 21 Jun 2001 02:31:09 -0400

> from themselves. Nor can I. 

Hmm. at the one end, is the "end point" the *browser*, or the person who's
doing the browsing?  Yes, a case can be made that you can't protect the
person (or the computer) from the browser - but we *should* be able to at
least draw a line on the floor and say "the browser and OPES can't collaborate
to do something contrary to what the source end wanted to transmit".

And for the record, I can think of *several* organizations that would be
at least very tempted to stoop to saying "our client software is non-malicious"
and not actually *lie* because some OPES agent is being malicious for the
client software.  Interestingly enough, the danger here isn't the pure
software houses - it's the companies that provide both software and content
(or wish they did) that are the threat here....

> can't say that's what OPES will do because the charter is too vague.

And I'm questioning the meaning at the end that isn't the web farm ;)

/Valdis

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2001 08:55:05 -0500

Eliot Lear wrote:
> use?  

Because both the content originator and the content receiver should be
able to veto (say) ad insertion.

> Consider a web farm.  How do we decide whether such "legitimate"

We can't make that judgement in a protocol design. All we can do is
provide functions. mo and others are saying we shouldn't even do that,
because they will be misused.

   Brian

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 21 Jun 2001 11:57:33 -0400

Brian,

> able to veto (say) ad insertion.

What about services that are executed only on behalf of the content
receiver? Virus scanning might be one example.

Other examples might be services that are authorized and performed on
the REQUEST issued by the content receiver (as opposed to the CONTENT
itself). Here, it seems sufficient if only the content receiver
authorizes the service.

-Markus

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Jun 2001 09:52:03 -0700 (PDT)

> able to veto (say) ad insertion.

But the content originator could have just as easily done the ad insertion
itself, and the receiver would have had no veto.

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2001 12:56:31 -0500

> itself). Here, it seems sufficient if only the content receiver

Yes, so there might be several classes of operation with different veto
rules.

  Brian

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Jun 2001 16:07:15 -0400

> Yes, so there might be several classes of operation with different veto

seems like the operations should be enabled only by affirmative consent,
rather than requiring parties to veto them.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 21 Jun 2001 13:30:28 -0700

Valdis.Kletnieks wrote:
> And for the record, I can think of *several* organizations that
> would be at least very tempted to stoop to saying "our client
> software is non-malicious" and not actually *lie* because some
> OPES agent is being malicious for the client software.

Actually the bigger threat is not that they would intentionally lie, but
that they would enable something like a java applet that was run hidden as
part of an inserted ad. It would be very easy for that applet to tell OPES
that this browser wanted the content mangled in a particular way. The
browser is doing the 'right thing', but the end user is totally unaware he
has authorized someone to prevent him from seeing original content simply by
receiving an unsolicited ad somewhere along the way. Couple that with script
enabled email and the spammers would have a field day basically because we
didn't have the wisdom to keep from giving them a standard mechanism for
authorizing rewriting of content.

If there is ever to be a case of preemptive termination of an effort within
the IETF, OPES is clearly one of them.

Tony

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Jun 2001 17:58:58 -0400

> Couple that with script

Not clear.  IETF folks had the wisdom to realize that allowing arbitrary 
MIME content to be automatically presented by mail readers was exposing 
the users to security risks, and to warn implementors of this fact.
That didn't prevent vendors from irreponsibly exposing their customers 
to those risks anyway.  IETF advice can be used as an excuse by vendors
who want to do the right thing, but it won't stop those who want to do
the wrong thing.

And it might be that IETF needs to make a statement about unauthorized 
modification of content (or that it should have made one a long time ago).
But it doesn't follow that OPES is the best means of doing so.

Keith

---

From: "Michael W. Condry" <[email-masked]>
Date: Thu, 21 Jun 2001 17:43:53 -0700

Interesting idea but not necessarily in the scope of OPES. Certainly
a ISV could offer a "list of services" so that any user or content provider
could get a yes/no/don't care for each service.

This fits our rule concept that OPES provides.

I do not know that OPES could force ISVs to manage there business
that way, however if all customers required it then either they
did it that way or had no business.  This might be a good
item to point out in the Deployment  Scenarios document.

>rather than requiring parties to veto them.

Michael W. Condry
Director,  Network Edge Technology

---

From: Keith Moore <[email-masked]>
Date: Thu, 21 Jun 2001 21:19:35 -0400

> Interesting idea but not necessarily in the scope of OPES. 

the point I was trying to make is that the services which OPES enable
should not be interposed between provider and audience without affirmative
consent by at least one of those parties - as opposed to a model in
which the services could be interposed by a third partry without either 
of the endpoints' explicit consent as long as neither endpoint specifically
objected.

Keith

---

From: "Michael W. Condry" <[email-masked]>
Date: Thu, 21 Jun 2001 17:31:09 -0700

The client or server can simply "not care".

The core is not having services executed on content (sending or recieving)
that is NOT wanted!! This is the idea of having our rule based
system were these wishes can be expressed from either end
and the policy will be allow for non-delivery/service to be
given if there is conflict.

Michael W. Condry

---

From: [email-masked]
Date: Fri, 22 Jun 2001 00:19:10 -0400

> of the endpoints' explicit consent as long as neither endpoint specifically

Point made quite well this time, I think.

Now if we only had a grip on what language we should use to deal with
things like Tony Hain's "rogue java applet" scenario.  I was around for
the same discussion for MIME a decade ago, and I'm convinced we made the
right choices on the technical design - but we could have done a lot
better at pointing out the dangers in not being *very* careful in
handling active content.

To paraphrase a T-shirt/poster:

"See Dick."

"See Dick Drink."

"See Dick Drink and handle active content."

"See Dick Crash."

"Dont be a Dick."

/Valdis

---

From: "Michael W. Condry" <[email-masked]>
Date: Fri, 22 Jun 2001 10:33:03 -0700

I believe we are in agreement. Some items, like ad-insertion, are
"by agreement" (like I will take ad-insertion in return for having Free DSL).

The rule model of OPES would allow both end to oversee the
operations here (like do not show my content with messy ads).

The enforcement side of things will hopefully result from guidelines
from our policy folks that will provide mechanisms to do this.

Michael W. Condry

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jun 2001 13:44:38 -0400

> "by agreement" (like I will take ad-insertion in return for having Free DSL).

given your choice of example, maybe we are not in agreement.

I don't see any way that OPES should be allowed to specify a means by which 
third parties (like ISPs) can modify packets in transit.  That is an
abhorrent practice, which IETF should not legitimize.

Keith

---

From: "Michael W. Condry" <[email-masked]>
Date: Fri, 22 Jun 2001 10:56:28 -0700

I assume you mean change "without permission" as opposed
to "by request".

Michael W. Condry

---

From: "Scott Brim" <[email-masked]>
Date: Fri, 22 Jun 2001 14:58:14 -0400

> abhorrent practice, which IETF should not legitimize.

Since this is by request, the only abhorrent part would be if when the
replacement or extra stream is finally delivered to you, it appears to
have come from the original source.  The rest I can live with.
Apparently the plan is that you have to ask explicitly that the packets
coming your way be diverted to some point where they are absorbed and a
new stream is sent your way -- packets are not modified, they are either
passed through or replaced completely.  Mail relays do something close
to that all the time, they just aren't as sophisticated in the request
and redirect mechanism.  However, you still know where the new packets
actually were sent from.

What will OPES-ified content have for source addresses?

...Scott

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jun 2001 15:04:06 -0400

> passed through or replaced completely.  

I hope not. if OPES is going to mess with the routing of IP packets,
it's abhorrent for entirely different reasons.

but the description of the group that we were given was so vague that
we really can't tell what OPES has in mind.  so we're doing a lot of
guesswork.

maybe someone should write up a completely new charter, which actually 
explains in precise, well-defined, technical terms (not marketing speak) 
what kind of protocol the group proposes to write, and how it interacts
with other protocol engines.

Keith