Re: An RFC from the IAB

["Jeffrey I. Schiller" <[e-mail]>]

On Mar 22, 11:00am, Brian Carpenter CERN-CN wrote:
> Subject: An RFC from the IAB
> Jon and Joyce,
> ...
> I haven't posted the -02 version, but of course I will do
> that if requested.

I never did see the -01 version, too much cruft going by on the IETF
list I guess. In any event:

> 6. Related to Confidentiality and Authentication
>
>    6.1 All designs must fit into the IP security architecture.

Do we really have one of these? We have an IPSEC architecture. The PSRG
has been working (on and off) on an Internet Security Architecture which
has turned into an opus maximus. How about changing this to a reference
to the Security Principals document published a few years ago.

>    6.2 Confidentiality and authentication are the responsibility of end
>    users and must be implemented in the protocols used by the end users.
>    Endpoints should not depend on the confidentiality or integrity of
>    the carriers, and in particular, it is not the responsibility of the
>    carriers to ensure confidentiality. Carriers may choose to provide
>    some level of protection, but this is secondary to the primary
>    responsibility of the end users to protect themselves.

Yes... but this reads too much to me as a license for ISPs to listen in.
I would prefer a preface along the lines of:

   "6.2 Providers of Internet services are expected to respect the
    confidentiality of information that they carry. However the ultimate
    responsibility of ensuring confidentiality and authentication belongs
    to end users. Endpoints should not depend..."

>    6.3 Wherever a cryptographic algorithm is called for in a protocol,
>    the protocol should be designed to permit alternative algorithms to
>    be used and the specific algorithm employed in a particular
>    implementation should be explicitly labeled. Official labels for
>    algorithms are to be recorded by the IANA.
>
>    (It can be argued that this principle could be generalised beyond the
>    security area.)
>
>    6.4 In choosing algorithms, the algorithm should be one which is
>    widely regarded as strong enough to serve the purpose. Among
>    alternatives all of which are strong enough, preference should be
>    given to algorithms which have stood the test of time and which are
>    not unnecessarily inefficient.

Do we want to say something about mandatory to implement algorithms in order
to ensure interoperability? IPSEC's ESP transform mandates DES (but other
algorithms choices can be used) so that two endpoints will always be able to
at least negotiate the use of DES if they have no other algorithms in common.

How about in addition:

   "6.5 To ensure interoperation between endpoints making use of
    security services, one algorithm (or suite of algorithms) should be
    mandated to ensure the ability to negotiate a secure context between
    implementations.  Without this implementations might otherwise not
    have an algorithm in common and not be able to communicate securely.

    In choosing an algorithm for consideration as the mandatory to
    implement algorithm (or suite) protocol designers should consider
    the required strength and performance characteristics for the
    application. Political considerations such as export control law
    conformance should play only a secondary role if any in this
    decision process"

[OK, so its a bold statement. Sometimes boldness is called for!]

                                -Jeff