RE: draft-ietf-cdi-threat-00.txt

>Draft looks good overall.  Some overall comments, then an edited
>version cleaning up some typos and confusing phrases here and there.
>Most important observation: the I-D purports to be about
>threats, yet mentions several times unintentional actions.
>To me, those are >not security threats.  For instance, someone who
>misconfigures the request routing unintentional may break things, but it's
not
>a threat to security.  Perhaps the title and abstract should change from
>"threat" models to "failure" models and emphasize that most of these, but
not
>all, are from explicit intentional threats.  Of course, some "threats" are
not
>actually "failures" so perhaps that doesn't quite work... maybe "threat and
>failure"??

Generally your are right. But I'd say that this are also threats, just not
security threats. One may also argue that there are threats to security
coming from unintentional actions.

"Security and other threats" looks closer to the point.
Can somebody suggest a better word instead of "other"?

>3.2.4.1 talks about a CN exposing passwords & credit card numbers.
>This seems to be supposing a lot -- are there CNs today that actually see
>credit card numbers?

This is just a standard example of something really scary :).

>3.2.7.2 refers to a location of a surrogate "generally transparent to the
>client".  To me "transparent" means it is NOT seen, but it sounds here
>like you mean "visible", the opposite.  No?

Maybe this section is not clear in the use of the word "client". The
human being usually points to the origin and is not aware that some links
are redirected to a surrogate. For the User Agent (browser) all connection
points are visible. Browser treats these new connection points as if they
are the content origin and may apply security settings based on the
surrogate location. The problem is that even if a surrogate is located on
the local network content coming from this surrogate should not be trusted
more than one coming from the origin server.

>In Sec. 5 it is "recommended not to send passwords in the clear" -- why
>not required?

Because this draft intentionally avoids imposing solutions. The idea is
to avoid use of SHOULD-MUST language and leave requirements to architecture
level documents. Maybe this intention was not followed meticulously.

Oskar