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

From: "Hilarie Orman" <[email-masked]>
Date: Fri, 15 Jun 2001 15:28:04 -0600

"Participation" includes "authorization" and is part of the security
model.  The notions of integrity and authorization are obligatory
in the WG documents.

Other WG's are concentrating on the network and transport layer
intermediaries.  We've got HTTP and possibly RTP.  

We have no control over whether or not functional layer
separation is abandoned.  It had seemed a personal matter.

The detailed wording of the charter comes from Area Directors;
I don't like the connotations of "arbitrary" and can see no reason
for using it.  However, it is scary to imagine the depth of the
paranoia that jumps from there to the end of the Internet
architecture.

The architecture is motivated by notions of dynamic content
and the notion of distributed semantic evaluation.  It is a logical
general of caching.

The technical issue of whether or not the IP addresses are honored
is outside the scope of the charter and the technology developed
therein.  If they aren't honored, OPES would not know, nor can
OPES force them to be honored, no more than it could prevent NAT
or Carnivore or a missile shield.

The OPES architecture and protocols go a long way towards building
an application friendly Internet by developing standards for a coherent
substrate for scalable application deployment.  This allows caches and
gateways to provide the services needed for rich content.

Hilarie Orman

>>> "Michael W. Condry" <[email-masked]> 06/15/01 01:51PM >>>
Keith-
We have no focus, interest, support, love for, etc. with interception proxies.
Of course we cannot control the ISV market and if they do/do not use them.

The intermediary service are at an application level not the network
level (NAT, etc.) and in some sense are an "end" in the "middle".
This space is short of clarifying terms and we hope to help that
shortly (a result of the last workshop). Certainly this is not
looking at the problems in the MidCom area.

This does not answer all your confusions, more later.

At 02:01 PM 6/15/2001 -0400, Keith Moore wrote:
>I have several concerns about this charter.
>
>I cannot tell whether those concerns are merely due to ambiguities in
>the charter.  I hope this is the case, and that the proponents of
>the group will be willing to clarify the charter to narrow the apparent
>scope of this proposed group.
>
>
> > The Open Plugable Edge Service (OPES) WG primary task is to define a
> > protocol to be used to extend participating transit intermediaries to
> > incorporate services executed on application data transported by HTTP.
>
>What are "participating transit intermediaries"?
>
>To me, an intermediary is anything that handles network traffic and
>which is not an endpoint, regardless of what layer of the stack it
>operates on, or on whose behalf it is operating.
>
>Do the charter authors intend that this group's purview include bridges,
>routers, NATs, proxies, firewalls, gateways, etc?    how about things
>that operate on multiple layers ?
>
>(If this group is approved are we abandoning the idea of functional
>separation between layers in the internet architecture? )
>
>Are "intermediaries" intended to include interception proxies?
>
>Does it matter whether the intermediary is operating on the client's
>behalf, on the content-provider's behalf, or on behalf of some
>communications provider?
>
>Re: "application data transported by HTTP" -
>
>Does this mean that this group's purview is limited to things that use
>the HTTP protocol?
>
>Are we now trying to encourage people to layer applications over HTTP,
>in spite of the concerns outlined in draft-moore-using-http-01.txt ?
>
> > The protocol provides a framework for integrating arbitrary services
> > into arbitrary intermediaries.
>
>The word "arbitrary" here is scary.  Is this group really being given
>a charter to allow it to entirely discard the internet architecture?
>
>In other words, is this group going to define standard ways to say
>
>- "yes, it's okay if you ignore the destination IP address for this
>    packet, and route it to some other location?"
>
>- "yes, it's okay if you break end-to-end transparency of the packet,
>   not just for the packet header, but also for the payload?"
>
>   (or similarly for end-to-end transparency of the transport protocol 
> stream)
>
>And who is allowed to consent to such deviations?  One of the
>endpoints or someone carrying the traffic?
>
> > Intermediaries may employ either local
> > or remote ("callout") servers to perform a service, and as a result,
> > the data may be diverted temporarily over a closed loop pathway
> > different from the transit pathway. Intermediary services provided in
> > this way are not transparent: Either the content requestor or provider
> > will be aware that a tranformation has been performed.
>
>Why is it (apparently) sufficient that one of the end points "be aware"
>that the data path is not transparent, rather than "consent"?
>
>Is this group really going to legitimize arbitrary corruption of the
>data stream by intermediaries which the endpoints do not control,
>just so long as one of the end points is "aware" of the corruption?
>
> > As part of the development of this protocol the WG will produce an
> > analysis of the security impliciations of this architecture.
>
>Why is security the only concern that the group is expected to analyze?
>It seems like reliability, predictability, ability to distinguish errors
>from normal operation, ability to diagnose and problems, user privacy, and
>intellectual property rights, are all at least as important as security.
>
>It also seems like there should be strict constraints on when this technology
>should be used.   If we do this work, will we be saying that it's legitimate
>for ISPs to rewrite HTTP requests or responses for better traffic 
>utilization?
>How about to insert or delete advertisements, or to hide content that the ISP
>doesn't want the user to transmit or receive?
>
> > A secondary task for this WG is to enumerate the requirements for
> > management policies and associated administrative protocols that allow
> > these services to be specified and deployed.
> >
> > The advantage of standardizing a protocol for this is that services can
> > be re-used across vendor products without modifying the transit
> > intermediaries or services.
>
>Something very important seems to be missing from this charter, namely:
>
>Why is this activity beneficial for the Internet user community?
>
>Or to put it another way (and if my understanding is correct), how is this
>protocol so valuable for the Internet community that it is worth destroying
>the Internet architecture ?
>
>(Or am I missing some implied constraints on the WG's charter that would
>make it reasonable?)
>
>
>
>This charter seems either dangerous, or dangerously ambiguous.
>I am hoping that it is the latter, and that the charter's intent
>is to do something reasonable and useful.  But I cannot tell from
>reading the charter what is reasonable and useful about what this
>group proposes to do.
>
>
>Keith

Michael W. Condry
Director,  Network Edge Technology

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 19 Jun 2001 12:44:26 -0600 (MDT)

> From: Brian E Carpenter <[email-masked]>

> ...
> Option 4 is not a separate option - it's a possible content
> provider reaction to whichever of 1, 2 or 3 takes place. As
> Mark pointed out, it has major scaling and trust model issues.
>
> If I'm right and OPES-like boxes are inevitable, maybe the
> IETF needs to start pre-emptive work on Option 4.

> ...
> > What about option 4, "information publishers who don't like interference
> > by transport providers use TLS/SSL to enforce actual end-to-end
> > transmission of the content" ? As we gain experience in implementing
> > TLS, this is a certainly a possibility!

How about starting at home by turning on STARTTLS for this mailing list?

Vernon Schryver    [email-masked]

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 19 Jun 2001 14:22:44 -0600 (MDT)

> From: Keith Moore <[email-masked]>

> so we increase the burden on publishers who want content integrity in the
> name of decreasing the burden on intermediaries who want to corrupt content?

Most publishers do not need use TLS/SSL or other end-to-end integrity
guarantees to fix the corrupters, but only enough to make their business
plans look stupid even to their prospective suckers--uh, I mean--investors.

Encouraging the development of services that corrupt content sounds
like the best way to finally get end-to-end security into the Internet.
The silly old nonsense about dirty evil nasty hackers with packet
sniffers capturing credit card numbers hasn't done the trick.
It probably needs reality.

> somehow that doesn't seem like a socially beneficial tradeoff.

Yes, needing to pay the various costs of locks, guns, guards, police,
armies, and so forth is an unfortunate consequence of living in big
cities instead of an isolated village.

---

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 19 Jun 2001 16:48:52 -0400

well
obviously you have missed the point.

abbie

> -----Original Message-----
> From: grenville armitage [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2001 3:44 PM
> Cc: [email-masked]; [email-masked]
> Subject: Re: WG Review: Open Pluggable Edge Services (opes)
> 
> 
> 
> > Abbie Barbir wrote:
> 	[..]
> > I do see that you are concerned, but the use of words
> > such as "primary purpose seems to be abusive" is totally 
> out of place.
> > I do not think the OPES guys are serial criminals?
> 
> From "abusive" you draw the accusation that OPES guys are serial
> criminals? Neat. You've just aptly demonstrated how what is said
> can be twisted into something that was not said. Then again,
> I guess that's the idea behind OPES.
> 
> gja
> 
>

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Jun 2001 9:28:41 EDT

It is interesting to see how the goal of scalable application and 
service deployment is being addressed in two completely different 
models.  On one hand we have OPES which will promote scalability by
following the mindset of the mid-90s that has continuously eroded the
end to end nature of the Internet.  And which in turn is scaring
several members of the IETF due to the resulting issues of trust and
power concentration.

On the other hand we have peer to peer development efforts such as
Project JXTA and APEX which can very well be seen trying to restore
the end to end model in an effort to enhance scalability and improve
the efficiency of use of bandwidth, storage and computing power. (As
we are all aware, the majority of all three now reside on the edges
and no longer in the middle of the cloud.)  

If I was forced to make a choice, it would not be a difficult one.
I would restore the end to end model. 

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Jun 2001 9:34:49 EDT

> As for the argument about "TLS everywhere", you have to ask who is 
> going to pay for it. The end-user cannot demand it; only the server 
> can. TLS is universally available today, and servers rarely use it 
> for anything other than getting credit cards or passwords.

Servers do not use it for everything because the cost of using TLS
with X.509 certificates from an entity such as Verisign are on the
order of $700 per server per year per hostname.  Why should anyone be
required to pay such an outrageous tax simply to be able to protect
their home photo collection from being tampered with in transit to 
a visitor's browser?

Granted, we could all become our own CAs, but that scares end users
and reduces the trust model because we don't want to train users to
accept a new CA cert from every site they go to.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 20 Jun 2001 11:18:40 -0400

Interesting discussion.  Couple of thoughts:

The use of words such as right and wrong or good an bad applied to the
engineering seem a bit premature, as the "engineering" work
doesn't yet exist.  It would be more intellectually honest to say
that the end goal of the proposed work does not match your value system,
which itself may not match the value system of others on this list.

It appears that there are four interests at work here:  that of the
network owner, the content provider, the content user, and the
middleman.  The role of the middleman may or may not be useful from
the perspective of the other three.  Whether and how the middleman
is used may/should involve the explicit knowledge and consent of the
other three interested parties.  The network provider may not want
his network abused by the traffic it carries, the content provider may
want control over how it is displayed, the user may want control over
what is presented or not.  I would require that the roles and
relationships be detectable and allow all possible relationship
combinations.  In the end the market will determine what works and
what doesn't (good/bad).

I have not seen where layering has been violated, as these all seem to be
occurring in the application layer above the core network layers and thus
end-to-end.  If I have misunderstood this, then please explain to me
how email is end-to-end.

Perhaps a set of objectives would help clarify/constrain the solution to
an acceptable end-result.  It might also be useful to describe some
of the potential middlemen and their functions that would be
"good" to have, as well as some potentail "bad" ones
and how they can be mitigated.

Mike

At 10:11 AM 6/20/2001 -0400, Abbie Barbir wrote:

Paul,

very good points.

Content/data is/are already being
changed/modified/adapted/etc  in transit and

the IETF must deal with it sooner or later.

Ensuring that the edge is dumb is not the way to protect the
end-to-end model.

The proper way to do it is to ensure that the edge is an
extension of the

source/origin. OPES can be used as a starting point.

abbie

> From: Paul Hoffman / IMC [mailto:[email-masked]]

> Sent: Tuesday, June 19, 2001 7:13 PM

> To: [email-masked]; [email-masked]

> Has everyone who has a reallyreallyreally strong opinion on this

> matter actually read the charter? Right there near the top, it says:

> >Intermediary services provided in this way are not transparent:

> >Either the content requestor or provider will be aware that a

> >tranformation has been performed.

> OK, so the spelling is not so great, but it sure is clear. What some

> people seem to be up in arms about is that the IETF would even think

> of helping someone change the content in HTTP. Data mungers are doing

> that already, and it is bad, and it is untraceable. So what should

> the IETF do?

> - Bury our head in the sand and at the same time keep yelling

> "end-to-end", thereby getting sand in our mouths and having the other

> people on the beach laugh at our collective and rapidly-aging rear

> ends

> - Let some other group create a standard, even though that group

> probably cares much less about both end-to-end integrity or alerting

> one or both sides than the IETF does

> - Create a standard that does a really good job of allowing one end

> (or, hopefully both ends) know what has been changed and why, in an

> interoperable fashion

> If my data coming or going gets changed, I want to be notified; that

> cannot happen now.

> Data is already being changed, some of in ways that we should really

> be unhappy about, and there is no way for the folks changing it to

> tell either end. OPES gives them that capability. Post-OPES, data

> will still get changed silently without using OPES, but at least

> there can be pressure put on the changers to use OPES so that someone

> sees what is happening. Without OPES, they never will.

> --Paul Hoffman, Director

> --Internet Mail Consortium

---

From: Jeffrey Altman <[email-masked]>
Date: Wed, 20 Jun 2001 12:34:39 EDT

> > order of $700 per server per year per hostname.
> 
> THe last time I checked Verisign's prices they were on the order of
> $250/year/hostname.  I think that's about 100 times too expensive
> given the uselessly superficial checking of the identity of 
> outfit buying the certificat (and I was saying that before the
> recent Microsoft circus.)

Strange.  I just purchased a 128-bit cert (can you believe they are
still selling 40-bit certs?) and the cost was $895 for the first
server and $695 for each additional server I wanted to be able to use
the certificate on.

If I wanted additional hostnames, they were additional new certs
starting at the base $895.  I assume it is possible to get better
rates if you are purchasing bulk licenses.  But this does not apply to
a small business with a single server and hostname.

> No, on several counts:
>   1. The only reason that might scare end users is because of scary
>     words from browsers, and then only for HTTP.  Browsers are not
>     too-smart-by-half SMTP MUA's not SMTP servers.  There are no scary
>     CA pop-ups from your browser-broken-MUA if you use SMTP for mail
>     submission.

This point is inappropriate at best.  We are talking about using TLS
to provide end to end security for a transfer of content.  The SMTP
MUA is not an end point.  It is one of the entities we are protecting
the data from.  You can't use TLS for that purpose with SMTP.  Once
the data has been delivered to SMTP via TLS it can still be tampered
with.  That is why you must use OpenPGP to protect your e-mail.  

All that TLS does when used with SMTP is verify that you are indeed
talking with the server you want to access; and perhaps protect your
password if you are not using client certificates to prove your
identity.

---

From: Michael Hammer <[email-masked]>
Date: Wed, 20 Jun 2001 12:47:08 -0400

Attempting to resend as plaintext per request.  Sorry for the extraneous 
format code.

>engineering seem a bit premature, as the "engineering" work doesn't yet 
>exist.  It would be more intellectually honest to say that the end goal of 
>the proposed work does not match your value system, which itself may not 
>match the value system of others on this list.
>
>middleman.  The role of the middleman may or may not be useful from the 
>perspective of the other three.  Whether and how the middleman is used 
>may/should involve the explicit knowledge and consent of the other three 
>interested parties.  The network provider may not want his network abused 
>by the traffic it carries, the content provider may want control over how 
>it is displayed, the user may want control over what is presented or 
>not.  I would require that the roles and relationships be detectable and 
>allow all possible relationship combinations.  In the end the market will 
>determine what works and what doesn't (good/bad).
>
>end-to-end.  If I have misunderstood this, then please explain to me how 
>email is end-to-end.
>
>an acceptable end-result.  It might also be useful to describe some of the 
>potential middlemen and their functions that would be "good" to have, as 
>well as some potentail "bad" ones and how they can be mitigated.
>
>Mike

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 20 Jun 2001 10:49:23 -0600 (MDT)

> From: Jeffrey Altman <[email-masked]>
> To: Vernon Schryver <[email-masked]>
> Cc: [email-masked], [email-masked]

> a small business with a single server and hostname.

When I was looking, I found that Thwate wanted $150 and talked about making
a profit despite being significantly lower than Verisign's pricing.  That
was before Verisign purchased Thwate.  I see that
http://www.verisign.com/products/site/pricing.html now starts at $350.

> password if you are not using client certificates to prove your

I've previously agreed with Paul Hoffman that SMIME, PGP, or whatever
is needed to really protect content from user to user.  However, we are
*NOT* talking about that.  The repeated claims or at least implications
that STARTTLS does nothing against the data mugging by interception
proxies are wores than "inappropriate at best."  If I didn't think
statements were merely the result of Verisign's and the FSF's effective
propaganda--er--sales information and the old syndrome of igoring the
better in perpetual, hopeless pursuit of perfection, I'd grumble about
shilling for snake oil.

In fact, STARTTLS would put a stop to SMTP interception proxies.
Also in fact, HTTPS wrecks HTTP interception proxies.

Yes, there are key distribution problems with both, but no more so than
with PGP.

---

From: "Joseph Hui" <[email-masked]>
Date: Wed, 20 Jun 2001 16:36:09 -0700

>Joseph Hui wrote:
>>
>> >On Wed, 20 Jun 2001 12:18:32 EDT, Keith Moore said:
>> >
>> >> but this isn't what's controversial about OPES.  what's
controversial
>> is the notion
>> >> that the transformations enabled by OPES might also occur in the
>> interior of the
>> >> network, without being explicitly authorized by either the source
or
>> the destination.
>> >
>> >Amen.
>> >
>> >A lot of things that OPES wants to do, I might want to use as a
content
>> provider,
>> >or as a content consumer.  It's that man-in-the-middle thing that
>> bothers me.
>> >
>> >--
>> >                               Valdis Kletnieks
>> >                               Operating Systems Analyst
>> >                               Virginia Tech
>>
>> 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.
>
>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

There're certainly discerning properties in edge pluggables that
differentiate them from the rogues amid the cloud.  If the protocol
is geared toward such properties, the concern that opes abets mayhem
may become a non-issue, or non-critical issue at most.

Joe

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 20 Jun 2001 23:30:09 -0600 (MDT)

> From: [email-masked]
> To: Vernon Schryver <[email-masked]>
> cc: [email-masked], [email-masked]

> ...
> I think you misread this - what Adam *meant* was that without a workable
> low-cost PKI system, or other means of distributing certificates, the
>person at the other end doesn't have a certificate to verify that an OPES-class
> mechanism hasn't done something ELSE to the bits.
>
> If I create a self-signed CA to protect my personal website on my
> computer, how do you get the certificate so you can verify that an OPES
> hasn't translated my text into an obscene poem in kanji?   That's
> the threat model here....

The counters to that threat model include the clunky one I've mentioned
several times.  I would fetch your self-signed certificate from your web
or FTP site or you would mail it to me as a MIME attachment or on a CDROM
or floppy disk.  If you've bought the expensive, $125-$900 commercial CA
story, I would not need any effort, but could use an existing list such
as is hidden somewhere inside Netscape and Internet Explorer.

Somewhere between one cert per SMTP peer and the commercial CA snake
oil, you and 10,000 of your closest friends could operate a cheap CA so
that I would need fetch only one cert to avoid Kanji translations for
all 10,000.  If I were among your 10,000 friends, I'd need do nothing.
What's missing from Openssl 0.9.5a for such a non-commercial, modest CA?

Yes, there are problems with this model, including some similar to the
problems with the PGP web of trust.  One of its special problems is that
end users for now would need to look at Received: lines for equivalents
of sendmail's "verify=OK/NO/FAIL/..." tokens. 

Still, if 30% of traffic were thus protected by STARTTLS, would the data
muggers bother?  Given 30% of HTTP and SMTP protected by TLS, wouldn't
OPES be safe to unleash on the Internet?  With 30% of content encrypted
and authenticated, how would OPES be an interesting plug-in except when
invited?

And yes, lest we go around that mulberry bush yet again, STARTTLS does
not protect against an adversary who specifically targets you.  STARTTLS
is good against the uninvited "we're from an ISP and we're here to help"
bulk manglers whose prospective paying customers are parties other than
the TCP ends, paying only a few $0.01 or $1.00 for ads to be inserted
into your messages or for your words to be checked for conformance with
government defined correctness.  Defeating adversaries looking for
$1000's or $1,000,000's is something else.

Besides, what barriers are there to low cost, low security PKI solutions
including:
   - netnewsgroups in which sites publish their certificates
   - the web directories that now contain phone numbers and email addresses
   - ad hoc, free or nearly free CAs
Note yet again that I did say *low* security PKI.  Protection from
routine translation to Kanji, ad insertion, and political correctness
filters does not need the high security mechanisms that protect the
secrets of nation states, drug dealing pedophile terrorists, and online
book and porn retailers.
Insisting that low security protections are worthless because they
are not high security protections is crazy.

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Fri, 22 Jun 2001 09:00:25 -0700

>would worsen the existing situation.

This is a good point. End-to-end encryption would eliminate most of the
possible threats identified in this discussion.