[Raven] Comments on Draft -- Take 2

Chris Savage <chris.savage@crblaw.com> Fri, 04 February 2000 21:39 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10963 for <raven-archive@ietf.org>; Fri, 4 Feb 2000 16:39:44 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13205; Fri, 4 Feb 2000 16:28:39 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA13176 for <raven@optimus.ietf.org>; Fri, 4 Feb 2000 16:28:37 -0500 (EST)
Received: from crbexch.crblaw.com (webaccess.crblaw.com [216.88.51.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10708 for <raven@ietf.org>; Fri, 4 Feb 2000 16:30:00 -0500 (EST)
Received: by webaccess.crblaw.com with Internet Mail Service (5.5.2448.0) id <12368GKG>; Fri, 4 Feb 2000 16:26:07 -0500
Message-ID: <D1A6C6C41B4CD311965D00C04F2C8D514526E3@webaccess.crblaw.com>
From: Chris Savage <chris.savage@crblaw.com>
To: "IETF Wiretapping List (E-mail)" <raven@ietf.org>
Date: Fri, 04 Feb 2000 16:26:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain; charset="iso-8859-1"
Subject: [Raven] Comments on Draft -- Take 2
Sender: raven-admin@ietf.org
Errors-To: raven-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Raven Discussion List <raven.ietf.org>
X-BeenThere: raven@ietf.org

Having been duly chastised for placing my comments into an attachment to an
email file, I am re-doing them in a format that works with text-only email.

The following are my proposed changes to Section 1 of the draft.  I would
characterize all of these as "editorial" rather than substantive, but, of
course, views may vary on that.  At least I am not consciously trying to
change what I understood to be the intent of the draft.

Here goes:

1. Summary position

. . . 

It takes this position for the following basic reasons:

[[[Replace this:]]]

-	The IETF, an international standards body, believes itself to be the
wrong forum for designing protocol or equipment features that address needs
perceived by national law, which vary widely across the areas that IETF
standards are deployed in.

	Bodies that are constrained to a single regime of jurisdiction are
more appropriate for this task.

[[[With this:]]]

-	The IETF, an international standards body, believes itself to be the
wrong forum for designing protocol or equipment features that address needs
arising from the laws of individual countries, because these laws vary
widely across the areas in which IETF standards are deployed.
 
	Bodies whose scope of authority corresponds to a single country are
more appropriate for this type of country-specific task.

[[[Replace this:]]]

-	The IETF, being a standards body for communications that pass across
networks that may be owned, operated and maintained by people from numerous
jurisdictions with numerous requirements for privacy, believes that the
operation of the Internet and the needs of its users are best served by
making sure the security properties of connections across the Internet are
as well known as possible. At the present stage of our ignorance this means
making them as free from security loopholes as possible.
 
[[[With this:]]]

-	The IETF sets standards for communications that pass across networks
that may be owned, operated and maintained by people from numerous
jurisdictions with numerous and potentially divergent requirements for
privacy. In light of these potentially divergent requirements, the IETF
believes that the operation of the Internet and the needs of its users are
best served by ensuring that the security properties of connections across
the Internet are as well known as possible. At the present stage of our
ignorance this means making them as free from security loopholes as
possible.  This is one of the IETF's principal goals with regard to this
topic. 

[[[The following paragraph now appears as the fourth under heading 1.  It
should be made the third and modified as follows:

[[[Replace this:]]]

-	The IETF believes that in the case of traffic that is today going
across the Internet without being protected by the end systems, the use of
existing network features, if deployed intelligently, will be adequate for
the wiretapping needs seen at present. The IETF does not see an engineering
solution that allows such wiretapping when the end systems take adequate
measures to protect their communications.

[[[With this:]]]

-	The IETF believes that, for traffic that is going across the
Internet today without encryption implemented at the end systems, the use of
existing network features, if deployed intelligently, provides extensive
opportunities for wiretapping. At the same time, the IETF is not aware of an
engineering solution that allows wiretapping when the end systems take
adequate measures to protect their communications.

[[[The following now appears as the third paragraph under heading 1.  It
should be made the fourth paragraph and modified as follows:

[[[Replace this:]]]

-	Adding a requirement for wiretapping will make the designs
considerably more complex, thereby jeopardizing the security of
communications even when it is not being tapped by any legal means; there
are also obvious risks raised by having to protect the access to the
wiretap. This is in conflict with the goal above.

[[[With this:]]]

-	Adding requirements to further enable or facilitate wiretapping will
make the designs of Internet protocols and equipment considerably more
complex.  Experience has shown that increased complexity almost inevitably
jeopardizes the security of communications even when those communications
are not being tapped by any legal means; there are also obvious risks raised
by having to protect the access to the wiretap. This is in conflict with the
goal stated above.

[[[Skip a paragraph, then:

[[[Replace this:]]]

-	On the other hand, the IETF believes that mechanisms for wiretapping
should be openly described, so as to ensure the maximum review of the
mechanisms and ensure that they adhere as closely as possible to their
design constraints. The IETF believes that the publication of such
mechanisms, and the publication of known weaknesses in such mechanisms, is a
Good Thing.

[[[With this:]]]

-	On the other hand, the IETF believes that mechanisms designed to
facilitate or enable wiretapping (or, if designed for another purpose, that
can be used for wiretapping) should be openly described. This openness will
permit maximum review of the mechanisms and provide opportunities to ensure
that they adhere as closely as possible to their design constraints. The
IETF believes that the publication of such mechanisms, and the publication
of known weaknesses in such mechanisms, is a Good Thing.

More to come....

Chris S.
All views/opinions my own...


*************************************************************************** 
This electronic mail transmission may contain confidential or 
privileged information.  If you believe that you have received the 
message in error, please notify the sender by reply transmission 
and delete the message without copying or disclosing it. 
***************************************************************************

_______________________________________________
raven mailing list
raven@ietf.org
http://www.ietf.org/mailman/listinfo/raven