Abbie,
Yet another significantly improved draft version, thank you!
Here are a few remaining (mostly high-level) issues that I could spot
after a quick review:
* Please cite RFC 2119
* In Section 3.2 "Requirements for OPES System" you list 5 MUST-level
requirements for adding information to the trace and then finish off
with informative (not-normative) text saying that most of the above
requirements can be satisfied by providing a URL to a web site. If we
ignore informative text, the requirements are likely to cause too
large trace entries. We need to convert informative text to a
normative one. For example, you could add another requirement similar
to the one below:
When providing required information, an OPES System MAY
use a single URI to identify a resource containing several
required items. For example, an OPES System can point to
a single web page with a reference to System privacy policy
and technical contact information.
I also believe that we must add explicit text clarifying the meaning
of the terms used by this section rules. Something along these lines:
This specification does not define the meaning of the terms
privacy policy, policy enforcement, or technical contact and
contains no requirements regarding encoding, language, format,
or any other aspects of that information.
In other words, we are saying that Systems must provide something that
they believe is a privacy policy or technical contact OR that other
specs may define these terms and details. This is a very important
"full disclosure" statement of our inability to fully address a known
problem.
An OPES system MUST add its identification to the trace.
Any requirements regarding System identification? Is it supposed to be
globally unique, for example? If yes, then are we proposing a registry
for system IDs?? If not, then a system can use "system" as an
identifier and satisfy the above requirement.
An OPES System MUST include information that identifies, to the
technical contact, the OPES processors involved in processing the
message.
This contradicts the fact that OPES processor tracing is not a MUST,
does not it? Given this two contradicting requirements, it is not
clear whether an end is guaranteed a processor trace entry for each
processor involved. Please resolve this important conflict.
Each OPES processor MUST support tracing, policy can be used to turn
tracing on and to determine its granularity.
I continue to note that the above requirement does not make much sense
to me. If a policy can be used, can I use a policy that always turns
tracing off and have that as the only, hard-coded policy? I think this
is a failed attempt to appear directly compliant with an IAB
consideration and it should be removed.
OPES processor SHOULD be able to trace it's own invocation and
service(s) execution since it understands the application protocol.
Is it a requirement or a consequence of the "since it understands"
part? There is another "SHOULD ... since" requirement elsewhere in the
draft.
* Please make sure that all "May"s are converted to "MAY"s or "may"s.
* Please include a Compliance Considerations section or equivalent.
What does it mean to be compliant with your spec? Are there multiple
levels of compliance?
the definition of "non-OPES" content is provider-dependent and may
include content adapted by OPES.
I agree with the first part, but cannot concatenate that with the
second part. Given an OPES-adapted content, a content provider may
designate any other content as a non-OPES content, but that designated
content cannot be OPES-adapted.
Examples include content that is adapted for Black
and White hand held devices or logging services.
Is this an example of non-OPES content or OPES content? Please give a
single example that contains both so that the difference becomes
clear.
An OPES System MUST include information about its bypass policy.
An OPES System MUST identify the party responsible for setting
and enforcing the bypass policy.
An OPES System MUST include information that identifies, to a
technical contact, the OPES processors involved in processing the
bypass request.
MUST include/identify where? In a trace? Then these should be moved to
tracing requirements.
OPES processor SHOULD be able to bypass it's own invocation
Isn't this a self-contradiction? Like lifting oneself by one's own
hair? If the processor is looking at the bypass instruction, it is
already invoked.
Specific protocol binding documents ought to take these security
threats into consideration. It is recommended that protocol bindings
provide safe features into their specifications. Such features may
include a place holder in the message header that indicates the size
of the trace.
I am not sure what you mean here. The documented security threats do
not seem to be application-specific so it it not clear why or how
application-specific specifications can "take them into
consideration".
* Please add "inconsistent/selective bypass" as a threat: One end can
try to bypass a subset of OPES entities so that the resulting
content is malformed and crashes or compromises entities that
process that content (and expect that content to be complete and
valid). Such exceptions are often not tested because implementors do
not expect a vital service to "disappear" from the processing loop.
* Please add "ACL bypass" as a threat: Systems implementing access
controls via OPES entities may be incorrectly configured to honor
bypass and, hence, give unauthorized access to the world.
* Please add "Tap bypass" as a threat: Systems implementing "wiretaps"
of all sorts via OPES entities may be incorrectly configured to
honor bypass and, hence, ignore (leave undetected) traffic with
bypass instructions that should have been tapped/logged.
* Do you already document a threat where one end can disable things
like virus checkers at the other edge? Please add if not. I am sure
you cover this in some general statement, but general security
statements are known to be ignored. We need specific examples to
get folks attention.
There are risks for the OPES System by non-OPES entities, whereby,
these entities can insert bypass instructions into the OPES Flow.
Isn't that usually the case that bypass instructions are inserted by
non-OPES entities (e.g., end-user browsers)?
The ability to illegally introduce bypass instructions into a data
flow
Do we define a legal way of introducing bypass instructions?
[5] Rousskov, A., "HTTP adaptation with OPES", Internet-Draft TBD,
Please update the above reference, including the authors list.
draft-ietf-opes-iab-02.txt, February 2004
What's the price of MS stock in your time zone? :-)
Thank you,
Alex.