Subject: RE: [Raven] Results of unofficial position tally

From: "Michael Welser" <[email-masked]>
Date: Wed, 1 Dec 1999 12:57:30 +0100

>     The question for the list was:
>
>         "Should the IETF develop new protocols or modify existing
>         protocols to support mechanisms whose primary purpose is to
>         support wiretapping or other law enforcement activities?"

My position is: No, the IETF should not.

Michael

PS: I would like to thank Thomas Junker for evaluating all those messages, and
also for some of his contributions which gave me some valuable insight on
possible differences in US-American and European attitudes towards democracy,
freedom etc. Nice reading you, Thomas [although I do not share your view on
guns] :-)

PPS: Over here, there are currently discussions on ENFOPOL which may lead to
decisions allowing (i.e. legalizing) police some major intrusion of our privacy
while Austria has prepared itself for the "Großen Lauschangriff" (something like
the big listening in attack [it is somewhat hard to translate]) - Europe IS
different.

_______________________________________________
raven mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/raven

---

From: Fred Baker <[email-masked]>
Date: Thu, 02 Dec 1999 11:46:51 -0800

At 03:59 AM 11/27/99 -0600, Thomas Junker wrote:
>Unofficial Raven list position summary

Thanks for putting the work into creating that summary.

One point to consider is that mailing list discussions often are tilted
towards the extremes of positions; those who are clearly in one direction
or another will make some form of a position statement, and those who are
activist in their chosen direction will often send a lot of mail advocating
essentially the same position. Those who are more middle of the road tend
to feel that their position is being adequately defended, or that they are
learning something in the exchange, and watch it. When there is a torrent
of opinion in one direction, especially when strongly expressed, it takes
courage to buck the tide, and many who disagree tend to find discretion to
be the better part of valor. This probably at least partly explains the
reason we have roughly 500 people on the list, only 141 people posting, and
only three taking a position that intercept tools should be supported. This
is one of the reasons we wanted to have a plenary discussion; discussions
tend to be a little more inclusive of the middle of the road, as one can
see when a speaker has the eyes of the room rolling into the backs of their
heads. And an unpopular speaker can see that he is being heard even though
he is being shouted down.

Your point about the topic drift is also important. This was mentioned
several times, most clearly by Grenville Armitage; unfortunately, the list
didn't appear to be interested in being guided back to the question. A
clear example of the point you are making is that both in the list and in
the plenary discussion, we had learned commentary to the effect that CALEA
is not applicable to the Internet. That is an interesting point, even more
interesting if it is in fact true (I am not taking a position at this
point, and don't claim to be a lawyer of any stripe). But as you point out,
it is not particularly relevant to the question at hand, as no country was
mentioned as being the locus of discussion. Similarly, polarized
discussions about the fourth amendment, privacy rights, and so on are not
particularly helpful, as such views are not universally perceived in the
same light, and we are by definition designing protocols for the Internet,
not the part of the Internet in a particular country. The question before
the house is what the IETF should consider to be its policy about features
in protocols, not what should be inferred from the first paragraph of any
particular country's constitution.

Something to consider (also not a position statement on my part) is that it
may be perfectly reasonable to design a feature into a protocol that is
illegal or not required in country A if countries B-Z require it, it is
optional, and can be disabled in country A. This is essentially the
position of those who feel we should design intercept features into some
protocols. Something else to consider is that not designing such a feature
is not going to prevent intercept; ask anyone who has used a LAN Analyzer
(or the equivalent diagnostic cards of high end routers and switches from
virtually any vendor) how hard it is to intercept traffic. In the words of
one private respondent, the lack of such a feature in standard equipment
probably creates an opportunity for a start-up company. I have spoken with
a member of congress and with FCC officials on this issue in person and in
email, and find that their issue is not with their ability to intercept
traffic, but their ability to obtain ONLY the information that their
warrant authorizes them to obtain, and in real time. If the counter to that
is a moral, legal, or ethical discussion, the place to have that discussion
is in the places where laws are made and applied, not the context in which
the tools they imply are built.

At the same time, the deep worry of those on the list who are passionate
about privacy is not only that the existence of the tools may be improper,
but that intercept tools that exist - LAN Analyzers and whatever else - can
be improperly used. I mentioned this point to an FCC official, and he
rather dismissed it with "well, then that use is illegal, and would get the
case thrown out of court". When I asked him "so what, isn't the whole point
here that people often do illegal things, and their motives may have
nothing to do with winning court cases, but with business intelligence,
blackmail, or worse?" he didn't answer me. A tool which can be improperly
used, by whatever the local legal definition of "improper use" may be, is a
dangerous tool, and it is this danger that caused us to raise the question
in the first place. If in the legal framework of country A, it is
illegal/inappropriate for a hacker to break into a system and turn it into
a LAN analyzer (something which is frequently done to insecure UNIX systems
- can you say "tcpdump"? - and is periodically reported in Internet
security reports when people try to sniff for passwords), it isn't adequate
(it is in fact naive and clueless) to say "fine, catch the guy and throw
him in jail." The facility must instead, or perhaps in addition, be made
secure, so that it can only be properly used. The technical civil liberties
argument (as opposed to the constitutional one) is that if it cannot be so
secured, it would be better if it didn't exist. However, of course,
features and equipment already exist and are widely - and often insecurely
- deployed that are capable of some kind of intercept, so this isn't
necessarily a useful position either.

What the IAB and IESG is wrestling with now is how to come up with a policy
statement, regarding IETF definition of features specific to wiretap, that
applies to the world in which we live and is useful guidance on such
features. If those who have posted to this list want to be really helpful
at this point, it will be by crafting a policy proposal that recognizes that 

  - Significant work is already ongoing in Packet Cable and T1P1
    on wiretap support.

  - the ability to intercept traffic exists already and is widely 
    deployed, and in many contexts (countries in which Internet 
    "wiretap" is legal, and for network management purposes) 
    is deemed to be perfectly reasonable by those who run the equipment.

  - the desire on the part of law enforcement is not to be able to 
    intercept information, but to be able to obtain ONLY the information 
    they are authorized to have, and in real time; more than that has 
    negative utility for various reasons.

  - Security is an issue that has to be addressed very well even if we 
    tell law enforcement that it has to live with today's intercept tools, 
    something which the IESG has been telling working groups for years 
    and routinely gets beat up for saying. Working groups tell us that 
    there is no market for protocols that are secure, and they back up 
    the statement with strong market data.

and by the way accomplishes the privacy goals that have been expressed.

---

From: "chefren" <[email-masked]>
Date: Fri, 3 Dec 1999 21:35:15 +0100

On 2 Dec 99, at 11:46, Fred Baker wrote:

> What the IAB and IESG is wrestling with now is how to come up with a
> policy statement, regarding IETF definition of features specific to
> wiretap, that applies to the world in which we live and is useful guidance
> on such features. If those who have posted to this list want to be really
> helpful at this point, it will be by crafting a policy proposal that
> recognizes that 
> 
>     something which the IESG has been telling working groups for years and
>     routinely gets beat up for saying. Working groups tell us that there
>     is no market for protocols that are secure, and they back up the
>     statement with strong market data.
> 

Maybe we should stick to these points for a while?

Is there someone who can point the list at basic 
information concerning Packet Cable, T1P1 and probably 
other details from the points above?

Thanks,

+++chefren