-----Original Message-----
From: owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-openproxy(_at_)mail(_dot_)imc(_dot_)org]On
Behalf Of Reinaldo Penno
Sent: Friday, October 25, 2002 2:05 PM
To: OPES Group
Subject: Some comments on draft-ietf-opes-threats-00
a) I propose a little bit of rewording on this paragraph
"These threats affect the quality and integrity of data that the
applications either produce or consume. On the other hand, the
security risks can also be categorized into trust within the system
(i.e. OPES service providers) and protection of the system from
threats imposed by outsiders such as hackers and attackers. Insiders
are those parties that are part of the OPES system. Outsiders are
those entities that are not participating in the OPES system."
These threats affect the quality and integrity of data that the
applications either produce or consume. -->On the other hand, the
security risks can also be categorized into those originating
inside the system (i.e. OPES service providers) and those
originated by outsiders such as hackers and attackers<-- Insiders
are those parties that are part of the OPES system. Outsiders are
those entities that are not participating in the OPES system.
With the rewording the last 3 sentences flow better since the inside and
outside
words are used in the sentence to categorize the threats.
Looks good, thanks.
b) Correct if I'm wrong here but it seems to me the (original?)
idea of this document was to document the *additional/specific*
security threats the addition of an OPES impose. The document as
it stands today basically lists more or less all attacks known
to man.
Take eavesdropping for example (2.1.4). The additional risk IMO
is only when somebody breaks into the OPES system and use that to
eavesdrop the traffic. Otherwise eavesdropping a network was and
is always possible.
Other examples such as a malign device impersonating a callout
server seems a little bit far-fetched since I would assume mutual
authentication and the like would make this a configuration error
instead of a threat...oh well...everything is possible.
The problem you are pointing to does exist, but I hope it is
limited to a few subsections in section 2, namely 2.1.1 - 2.1.5.
It's unfortunate if these subsections have a negative impact on the
reader's attitude as they come before description of specific
OPES-related threats. Maybe these subsections should be compressed
into one that emphasizes OPES-related aspect of these generic
threats.
c) "A serious problem is posed by the very fact that the OPES
architecture is based on widely adopted protocols (HTTP is used as an
example)."
Is this really a problem? It seems to me it would be problem is it is
(widely deployed + not mature and/or not open), such as some P2P protocols.
Widely deployed alone does not make it a security problem.
The problem is posed by the fact that we intend to use not only the
HTTP but also the existing user agents (browsers). This seriously
limits system abilities to mitigate threats by adding protocol
extensions - like special message structure, tracing/notification
headers, signatures that are transparent to non-OPES aware
counterparts and other similar things.
Existing browsers are not aware of such additions and
will simply ignore any discrepancies caused by security
violations.
Oskar