Re: Split the IANA functions?

[Stephen Kent <[e-mail]>]

Eliot,
>
> Why do we state that confidentiality is important to pursue in our
> protocols?  That is a political decision made by the community.  We then
> layer on top of that decision technical requirements.  IMHO it's a very
> important and good political decision.
Confidentiality is not an IETF-specific notion.  Long ago (mid-80's) the
ISO published a doc, ISO 7498-2, which describes security services and
mechanisms. That doc defines confidentiality as a security service, and
encryption as a mechanism that can be used to implement the service.

The same doc defines authentication, (data) integrity, access control
and other security services, with several variants of each service to
be more precise. It also includes a description of numerous security
mechanisms.  While 7498-2 is not perfect, it does demonstrate that a
large community (after all, it's an ISO doc) viewed these services as
generally desirable characteristics for communication systems. Thus
when the IETF says (as we did long ago in 3552) that confidentiality
(and authentication and integrity) are good things, we are consistent
with long-established principles that extend far beyond our standards
environment.

I see the political aspect of our current discussion as how we choose to
make tradeoffs between the security and privacy aspects of our protocols,
vs. other aspects of protocol design and network operation. Stephen's
doc does not address these tradeoffs in any detail. So, if we avoid terms
(near the end of the doc) that might appear to establish the rules for
evaluating these tradeoffs, we can make a statement that is not perceived
as political. Most means of effecting PM are attacks, as per 3552. This
ought not be viewed as a debate relative to our previous docs. I'd
prefer if this doc noted that, and explained what aspects of PM don't
neatly fall under the old threat model, thus providing a motivation for
a new threat model.  That way this doc can be seen a a simple statement of
the consensus from Vancouver, and an indication that the IETF has plans
to address concerns about PM, as established by the consensus.

Steve