Re: An RFC from the IAB

Robert Elz <kre@munnari.oz.au> Wed, 27 March 1996 03:09 UTC

Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01040; 26 Mar 96 22:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01036; 26 Mar 96 22:09 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa17706; 26 Mar 96 22:09 EST
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01029; 26 Mar 96 22:09 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01025; 26 Mar 96 22:09 EST
Received: from munnari.OZ.AU by CNRI.Reston.VA.US id aa17687; 26 Mar 96 22:07 EST
Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.55) id DA25329; Wed, 27 Mar 1996 14:07:14 +1100 (from kre@munnari.OZ.AU)
To: "Jeffrey I. Schiller" <jis@mit.edu>
Cc: iab@isi.edu, iesg <iesg@CNRI.Reston.VA.US>
Subject: Re: An RFC from the IAB
In-Reply-To: Your message of "Fri, 22 Mar 1996 15:26:47 CDT." <9603221526.ZM17665@bozo.MIT.EDU>
Date: Wed, 27 Mar 1996 14:07:05 +1100
Message-Id: <6638.827896025@munnari.OZ.AU>
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Robert Elz <kre@munnari.oz.au>

    Date:        Fri, 22 Mar 1996 15:26:47 -0500
    From:        "Jeffrey I. Schiller" <jis@mit.edu>
    Message-ID:  <9603221526.ZM17665@bozo.MIT.EDU>

    >    6.2 Confidentiality and authentication are the responsibility of end
    >    users [...]

    Yes... but this reads too much to me as a license for ISPs to listen in.

No, I don't think so, what it says is that carriers (ISPs, and
no doubt others) may provide some confidentiality protection,
but you can't rely upon that, its the user's responsibility.

It says nothing at all about permitting anyone to snoop - there's
a big difference between watching traffic, and actively stopping
others from watching.

    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.

This is a totally different issue.   It probably belongs being
stated somewhere, but it isn't an architectural principle of the
internet, its more the ethics of ISPs.    That is, we don't go
designing the internet architecture assuming anything about what
providers of internet services will do wrt confidentiality.   We
do however design that on the assumption that privacy is the end
user's ultimate responsibility, hencee the previous version is
correct.

    Do we want to say something about mandatory to implement
    algorithms in order to ensure interoperability?

Yes, that's probably a good idea.

    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.

I'd agree to there.   We could even cut out the last sentence,
the rest of this doc isn't big on justifications of the
principles, just statements of them, so, better not include
that in this case either.   Perhaps even stop before "to ensure".

    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.

I don't think this doc needs to go into quite that level of
detail.

    Political considerations such as export control law
    conformance should play only a secondary role if any in this
    decision process"

While I certainly agree with that, I also don't believe it needs
to be stated here.

Brian's "we may not be able to do this because we have a toehold
in France" thing is exactly the kind of argument that we must
ignore - but it doesn't need to be ignored here (somewhere
else is fine).

kre