Subject: Re: [Raven] Re: (no subject)

From: "Thomas Junker" <[email-masked]>
Date: Mon, 29 Nov 1999 19:31:43 -0600

On 29 Nov 99, at 23:46, chefren wrote:

> On 25 Nov 99, at 13:55, Ray Yang wrote:
> 
> > Sorry if I'm wrong (and please do correct me), but I was under the
> > impression that the IETF was a standards-setting body. That meant that
> > anything done to support tapping would mean creating a standard for
> > tapping. 

Ray, the issues that led to the IESG's question in 
creating this list were far less general and far more 
specific to voice-over-IP than what you seem to think.  
The IESG's policy question was general, but it seems to 
have been prompted by the telephone people working on 
voice-over-IP issues.  It was chefren who tried to divert 
the discussion to general wiretap issues and "auditable 
taps."

> > Since such a standard could not include legal remedies
> > (because the IETF has no legal power), the standard would 
> > have to be primarily technical in nature. A technical standard 
> > would be something like a 1-2-3 process for tapping -- which 
> > would make it easier than it is now.

No standard is required for law enforcement to execute a 
warrant by clipping onto a phone line or by forcing a 
carrier to provide a copy of a traffic stream.  You can be 
sure that the voice telephony vendors have addressed and 
continue to address such issues with no help from the 
IETF, which is concerned only with the Internet world of 
IP traffic.  Where standards would come in would be in the 
design of things like voice telephony gateways, where 
presently tappable types of traffic *might* come under 
wiretap requirements either at the voice circuit or IP 
level or both, or might in some interpretation or future 
law become tappable in transit in IP packets.  Where the 
vendors are anxious to have standards is in things like 
the protocols or extensions to protocols to expose things 
like call setup and conferencing call management 
information, and perhaps in the precise forms in which 
they will deliver authorized levels of information to 
authorities.  As I understand it, the IETF has no possible 
role whatsoever in the vast field of general wiretap, only 
in the projected field of IP wiretap, particularly as it 
may expand due to existing conventions for voice 
wiretapping spilling over into voice-over-IP.  Even in IP 
matters, IETF as an informal body with no authority can 
take or leave the issues as it chooses.  IETF's protocols 
are used or not used by the world solely on the basis of 
their value to those engaged in IP networking and 
applications.

> Not necessarilly =easier=!!! Technicians have concluded 
> long time ago, nothing is more easy than tap with the 
> tcpdump utility that's widely available.

Which is irrelevant, chefren.

> Since that's not very auditable it's not very usefull in 
> court.

As with any other form of evidence, it is useful or not 
according to local legal rule, not according to anything 
chefren says or the IETF says.  A U.S. lawyer pointed out 
to you that modifiable forms of evidence are very commonly 
used in court.  Indeed, digital signature variants of 
encryption only recently provided any means at all to make 
certain kinds of evidence verifiable -- all through the 
history of law and courts, most evidence has been of a 
much more tenuous nature than what you seem to hold up as 
a standard.  Even so, it has also been pointed out to you 
that your "auditable tap" can also be deceived, since it 
is not the entire network.  I would go a step further and 
point out that your auditable tap could result in grave 
harm to individuals due precisely to its presumed 
security.  It would be much more difficult to demonstrate 
in court how the presumably "perfect" and "honest" 
auditable traffic may have been falsified by authorities 
or others, particuarly if the malefactors were a jump 
ahead of the authorities and general public and used a 
tecnique not yet widely understood.

If your position is that having a standard for such 
"auditable taps" might influence national legal 
authorities to tighten the standards of wiretap evidence, 
that is a valid and possibly meritorious suggestion, but 
has little or nothing to do with the question before the 
IETF except possibly as a very fundamental explanation for 
expressing "Yes" to the question posed by the IETF.  Had 
you done that I would have had no complaint even if I 
disagreed with your reasoning.

Unfortunately, though, in over 160 messages, only once 
have you even come *close* to stating anything that 
relevant, that clearly.  Were you to take that position, I 
would agree that the objective is worthwhile, but would 
still suggest you take the details to the proper forum, 
which is NOT HERE.  The IETF has places to propose and 
discuss protocol standards -- things generally of interest 
to the Internet community -- and it is your job to find 
out where they are, not the job of anyone here to do your 
homework for you.  I reply to some of your posts only to 
counteract the profound misinformation you are 
disseminating in support of your off-topic proposals.

> > To be
> > redundant, the process would be standardized -- made easy, and massively
> > reproducible. Maybe it won't initially be as easy as a point-and-click,
> > but given the capabilities of modern computers to automate lots of tasks,
> > I don't see how such a standard, if introduced, could be prevented from
> > going there. 
> 
> Yes!

You've just agreed with the proposition that advancing a 
standard facilitating wiretap would inevitably lead to 
more widespread wiretapping, which is probably the most 
basic reason for opposition by most of those opposed to 
facilitating wiretapping.  I think that means you have now 
managed to take both sides of virtually every issue you 
have so far raised.  That's probably an achievement, even 
for USENET.

A technical standard cannot possibly enforce itself, 
particularly outside the technical realm in the legal 
realm where concepts like "sealed equipment" and 
"auditable taps" and evidentiary standards live.  My 
contention is not that such stringent requirements on law 
enforcment would not be a good thing, but that they are 
irrelevant in a technical body concerned only with 
protocols, and non-obligatory protocols at that.  I 
further contend that your starting point for something so 
distinctly non-technical has to be in the legal arena.  
Purely technical standards arise for technical reasons, in 
solution of technical challenges.  Extra-technical 
standards that affect technical issues, such as legal 
requirements for "auditable taps" and secure forks in 
traffic streams, probably begin only poorly in the 
technical arena, best originating in the legal arena in 
consultation with technical people on what is technically 
feasible.  What is legislated can then be met with 
workable standards.  What is not yet legislated is pure 
speculation, and wildly different from country to country 
in local customs and requirements, both of which change 
unexpectedly for completely non-technical reasons.

Regards,

Thomas Junker
[email-masked]

The Unofficial Wang VS Information Center
http://www.phoenix.net/~tjunker/wang.html

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

---

From: Sampo A Syreeni <[email-masked]>
Date: Tue, 30 Nov 1999 15:25:51 +0200 (EET)

>specific to voice-over-IP than what you seem to think.

There's also the problem of new protocol evolving and government needs for
tapping overall. It is not entirely clear CALEA requirements can be met in
the long term for VOIP without messing with other parts of the internet
arhitecture as well. For instance, sometimes warrants are issued for
connection setup data only - does that include data included in ICMP
messages as well?

>the discussion to general wiretap issues and "auditable 

Although the original question was a simple yes/no one, I do not really see
how to work on the subject if the results of the decision and the means
needed to achieve them are not discussed as well. Had the original question
just been an invitation to vote, I think there would be no raven /list/ but
rather an opinion poll on some suitable WG homepage.

>IP traffic.

Assuming net security standards proliferate (e.g. IPSEC, SSL, SSH), some of
them might cover VOIP as well (like IPSEC). In this case meeting CALEA
requirements would probably mean weakening the security part (obviously
IPSEC encoded data streams will not be very tappable). This might have some
pretty serious consequences on developing unified e2e encryption and related
technologies.

Chefren's sometimes off-point ranting about auditable taps might actually
have some bearing, here: one noteworthy question is whether legistlative
demands can be met by providing court admissible dumps or is realtime access
to the (possibly decrypted) data stream necessary? This is a fundamental
question in that it defines what we are actually answering to the 
IESG: yes/no to new protocols for gathering court admissible evidence or
yes/no to realtime access to data carried by existing protocols?

>Even in IP 

Precisely. If tapping-frienly protocols are developed by IETF, they probably
will not be adopted. Worldwide, at least, since theoretically the US
government could force people to settle on a technical standard. That is why
I do not see why IETF should put any effort to the development of such
standards.

There it is, then: count my vote as 'no'. Effort should not be wasted on
developing capabilities which benefit someone other than the end-user of the
Net or protocols which are not likely to be widely adopted.

>protocols, and non-obligatory protocols at that.  I 

Currently IETF is, more and more, a forum for just about everything related
to the Internet. And every technical decision the IETF makes has its reasons
and consequences in the outside world. To decide whether steps should be
taken to explicly aid tapping, it's pretty important to know what sort of
steps are needed to fulfill the requirements that originally drove the IESG
to pose the yes/no question. That is where law starts to rear its ugly head.

Sampo Syreeni <[email-masked]>, aka decoy, student/math/Helsinki university

---

From: Ed Stone <[email-masked]>
Date: Tue, 30 Nov 1999 09:24:56 -0500

>rather an opinion poll on some suitable WG homepage.

The "original question":

"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"

and

"what should the IETF's position be on informational documents that explain 
how to perform message or data-stream interception without protocol 
modifications".

The first question is a yes/no question.
The second question would be answered with a recommended position.

To work on the subject (question one) does not require one to develop or 
put forward wiretapping protocols for evaluation. To the contrary, that 
would cause a premature technical discussion to displace and obscure the 
overarching philosophical question that was properly posed.

Working on the first question posed requires one, if one has a position, to 
state whether or not one favors having "the IETF develop new protocols or 
modify existing protocols to support mechanisms whose primary purpose is to 
support wiretapping or other law enforcement activities".

A proper response to the question "Should we give the police department a 
key to the front door?" would be "yes (and optionally with reasons)" or "no 
(and optionally with reasons)". It would **not** be "The key we give them 
could activate 10-pins, be made of steel, and they could give us a receipt 
for it, and agree to tell us within six months of their use of it." Even 
further distracting from the issue at had ("should we") would be the 
inevitable response, "it should have 12-pins, be made of brass, and they 
must agree to tell us within 90 days".

While advocates of having IETF develop or modify protocols to support 
wiretapping would very much like to detour around that overarching 
question, and proceed directly to "HOW" (how to engineer aids to 
wiretapping so that we can become ensnarled in technical debate and tap 
facilitating), the original question was very properly provided as a 
"SHOULD WE" question.

Least persuasive, and even damaging to the frail point made, is the 
assertion that the existence of a discussion list is indication that the 
question posed was not to receive "yes/no" treatment. As if one's "yes" or 
"no" would not have a "why" behind it that merited discussion!

The first point seems to be "before we consider whether or not IETF should 
develop or modify protocols to support wiretapping, let's have the IETF 
develop or modify some protocols to support wiretapping!"

The second point seems to be "if you are for or against having the IETF 
develop or modify protocols to support wiretapping, keep your reasons to 
yourself!"

The "should we" question is properly posed, and is NOT answered with 
"here's how".
--
--------------------------
Ed Stone
[email-masked]
--------------------------