Alyn, these are the comments I referred to in my other email. I've picked
out some points from the discussion that I think are relevant to
MIMEsweeper/WEBsweeper type concerns.
#g
--
At 01:29 PM 1/14/02 -0500, Allison Mankin wrote:
Decisions/Action Items:
Those present agreed that the IAB document (IAB Architectural
and Policy Considerations for OPES) presented a valid
set of concerns and that work on OPES could proceed according
to the guidance of the document.
In the spirit of usual IETF process (even if this isn't quite "usual" ;-)
I'd like to use the mailing list express a reservation about the IETF
document, even though I was silent in the meeting ... (I did have my
concern in relation to the original IAB document, but I'll use your summary
to indicate it):
To summarize the IAB issues: at least one party must consent to the
use of the OPES intermediary; the OPES intermediary must be explicitly
addressed at the IP layer by the end system;
OK so far.
the OPES system must
assist content providers in detecting and responding to client-centric
actions that are deemed inappropriate by the content provider;
This is the part about which I have reservation. I think there are
legitimate reasons why a client, or an agent acting on behalf of a client,
may wish to have content processed without allowing the content provider to
discover that this is happening; e.g.
- content filtering on web traffic, such as viruses, pornography or
advertising filters. I can see no justification for requiring the client
to advise the content provider that filtering is being applied, since that
may provide information that can be used to circumvent the filters.
- similar filtering on email; similar arguments.
- I could imagine that reporting of content adaptation intermediaries might
result in disclosure of private information ("for this client, all content
is being adapted to Braille").
I think provision of the detection-and-response capability within the
protocol is OK, but I think the client, or client's agent, must be able to
disable such reporting.
the OPES system must assist end users in detecting the behavior of OPES
intermediaries, potentially allowing them to identify imperfect or
compromised intermediaries; the OPES architecture must not prevent
users from accessing non-OPES content from content providers if such
content is available; and it must be clear where such services are the
result of URI resolution that the services do not constitute URI
Resolution.
This seems OK to me.
...
Regarding some discussion which might argue against my point above:
Sally: Imagine a virus scanner that refuses to let through a document
on viruses or a language translation service that mangles an
internationalization document; what recourse does the content owner
have to know that an OPES intermediary is present and having an
effect? That is the issue; the document is not prescriptive on how to
deal with that.
Ultimately, who is in final control of what arrives at the recipient's
system? The sender or the recipient? I think it's the recipient. I think
it's unrealistic to insist that a sender will have a right to to discover
any modification or non-acceptance of possibly malicious content.
[...]
Leslie: Effectively, OPES is discussing extending the boundaries of a
client or a server; the question that raises is whether that is really
IETF work. There are lots of things inside clients or inside servers
that do not meet these requirements, but those are not IETF work.
I think the IAB recommendations take the OPES idea somewhat further than
extending the boundaries of a client or a server. Effectively, the point
of my concern is that it's trying to dictate what a receiver
(extended-client?) does with information provide by a server.
[...]
David Martin: Draft appears to require the ability to peer into
different administrative domains (thinking mobility as an example).
Leslie: you can address this in terms of privacy concerns, but you
need to be able to see this in terms of building blocks for an
infrastructure. Whenever there is content manipulation, you have
risks for content applications failing to interact correctly.
David: This goes beyond previous requirements though, to request a
notification model.
Sally: yes. This is a detection mechanism that addresses failures of
OPES intermediaries and related robustness issues.
Again, I'd say that defining reporting/notification mechanisms is one
thing, but insisting that they be enabled really does open a can of private
worms. (Hmmm... can worms blush ?-)
[...]
Eliot Lear: In general, this document is great way for the IAB to show
leadership. I do want to say. though, that using the client selecting
an ISP to infer that the client buys into its trust realm or
application architecture leads us down a slippery slope.
Leslie: true, and far more general than this specific work.
Absolutely! For many of us (outside N. America), any apparent choice of
ISP is an illusion.
[...]
Ned: We need to make sure that the solutions are available, rather
than making sure people use it. Think about mandatory to implement
security issue. We may demand that TLS be present in a protocol, but
it does not imply that all of it always runs on top of TLS.
I think that's the right level of approach, but it's not clear (to me) in
the IAB document.
[...]
John Wroclawski: We have to find a balance among the various people
struggling to get their view heard. The IAB names that balance here
as "you can protect your interests, but you have to tell people what
you are doing". That's a good balance, and it is part of a good
battle.
I don't entirely buy that, in that telling people what you are doing can
compromise the protection. E.g. it seems to accepted in other IETF
activities that one can hide one's i9nternal network topology, even if that
may reduce the effectiveness of debugging information (DNS reporting
springs to mind; I expect there are others).
[...]
Eliot: The content owner gets to say what is correct.
Eh? The virus writer gets to say that correct is when your machine is
infected?
...
Mostly, I think the IAB paper is fine ... I'm just concerned that it pushes
a little too far in one or two places. My comments have focused on
notification provided to content providers. Similar concerns might apply
re. notification to receivers, though maybe less urgently.
#g
------------------------------------------------------------
Graham Klyne Baltimore Technologies
Strategic Research Content Security Group
<Graham(_dot_)Klyne(_at_)Baltimore(_dot_)com> <http://www.mimesweeper.com>
<http://www.baltimore.com>
------------------------------------------------------------