From: John Martin <jmartin(_at_)netapp(_dot_)com>
There has been a lot of discussion about the problems associated with
so-called "interception proxies". This discussion is very much within the
charter of the WREC WG. In fact, we even have a current draft whose sole
purpose is to document such problems.
The known problems draft is at: draft-ietf-wrec-known-prob-01.txt
This is the first of two very useful documents being produced by WREC; the
first, a taxonomy of terminology is available as:
draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first.
The problems draft is interesting and depressing. All of the problems
listed are technical nits. If you assume that "traffic redirection"
and an "interception proxy" are good things, then you might well worry
about the "lack of HTTP/1.1 compliance for proxy caches" or whether
"interception proxies break client cache directives." You will not
question their desirability or even their long term utility in the face
of actions by users to protect their privacy or defend against censorship.
You won't even worry about what's going to hit the fan when the big
advertisers realize that their wonderful ads are being filtered and
overwritten with other people's ads by interception proxies.
I don't know whether to be depressed, encouraged, or neutral that WREC
seems to not be about port 25 traffic redirection and interception proxies,
such as AOL's effort. That there is no mention of the problems that IP
fragmentation can cause interception proxies is depressing.
To join WREC, use the following:
...or send a note to wrec-request(_at_)cs(_dot_)utk(_dot_)edu with
"subscribe" in the subject.
I suggest we move this particular discussion to WREC.
Joining that mailing list would not be useful, prudent, or honest for
people with sentiments like mine. Moving the question of the wisdom of
such proxies to WREC would be equivalent to moving the question of the
wisdom of wiretapping to the wiretapping working group. At best the group
WG consensus can be predicted. At worst, the discussion would legitimately
be considered disruptive and irrelevant.
It appears that the WREC working group is doing exactly as someone
lamented a day or two ago about working groups in general, and not
considering the question of whether the mechanisms they are working are
good ideas in the larger scheme of things. WREC is only concerned with
making them as good as possible. (Yes, I checked recent months of the
archives at ftp://cs.utk.edu/pub/wrec/)
It is interesting, but consistent with that observation that the problems
draft contains no mention of problems should clients use end to end
encryption or even just authentication with message authentication codes
that care about the current time or the particular client. I don't know
what to think of the absence of the string "https" in all three drafts.
The passing, convoluted reference to encryption and SSL in section 9.2.2
of the taxonomy draft confuses me. If I were optimistic, I would hope
that the taxonomy document is the wrong location is the reason its privacy
section is so shallow.
Vernon Schryver vjs(_at_)rhyolite(_dot_)com