RE: [Raven] Comments on Draft -- Take 2

["chefren" <[e-mail]>]

On 7 Feb 00, at 15:22, Chris Savage wrote:

> >From: chefren [mailto:[e-mail]]
> >On 7 Feb 00, at 12:13, Chris Savage wrote:

> >IETF should look primarily at technical side of the 
> >problem, that's pretty simple: pass al information to and 
> >from an IP address without changing the information. The 
> >information should be encapsulated in a timestamped package 
> >with details like who had set the tap, which warrant, 
> >checksums against modifications and so on. Not that 
> >difficult.
> 
> You can't avoid the legal problems, unfortunately.
> 
> The solution you just described -- ship all the data to someone (LEA?) who
> will agree to only look at the stuff they are entitled to -- would probably
> affirmatively violate CALEA in the US, which requires (lots of glossing over
> of details here) giving the LEAs what they are entitled to, but not more
> than they are entitled to.

That's important basics for serious tapping, not tapping 
streams or data of other channels. "Sleepnet fishing" is 
out of the question.

> In the case of IP addresses, most consumers here
> (targets of taps) access the 'net via dial-up, and ISPs typically
> dynamically assign IP addresses to dial-up users.  So I don't see how your
> proposal would give the LEAs either (a) all the information regarding
> someone they are legitimately tapping (different IP addresses for different
> sessions) or (b) only the information they are entitled to (since different
> users would have the same IP address over time).

Right!!!

So this is why central, IETF, standards are necessary.

Take your example, the equiment that receives a dial-in-
call and checks name and password has to program the 
routers dynamically. Not very difficult but definitely 
needs standards.

> The discussion above has at least met, and probably exceeded, my actual
> technical knowledge.  But if it is even remotely right, your solution might
> be okay under Dutch law, or some other country's law, but I don't think it
> would cut it in the US.

True for here too. And the worst part is: The law states 
the providers have to serve all this around December, after 
a 2 year "grace" period.

Without good standards it's impossible so what happens: A 
very bad kludge of solutions will appear that definitely do 
nothing good for privacy.

> Here the FCC is in court defending a decision to
> approve, on what amounts to an interim (and probably
> never-to-be-implemented) basis, a system where the LEA gets full packets
> to/from a target when their authorization extends only to address
> information, not content.  So you can imagine what would happen with a
> system that gave full packets from lots of people in order to allow the
> capture of data relating only to one or a few...

That should be prevented.

Now the access providers, typically more or less low-tech 
guys that buy high end hardware and software, have the law 
that presses them to do it good and the industry that 
doesn't deliver because lacking standards.

..

> >I don't see the necessity of a bunch of lawyers. This can 
> >and should be handled strictly as a technical problem.
> 
> This is probably where you experience the greatest disconnect with a lot of
> other people on the list, IMHO.

  Probably "the other people on the list" were never
  involved in design for tapping before. My company met
  telephone tapping by accident 10 years ago because our
  digital recording machines had better sound reproduction
  quality than other machines with 2 times compression and
  the SCSI storage technology was flexible enough to store
  so much on a tape that lots of things could be automated
  in a way that prevented recording errors, exchange of
  data between different cases, editing of tapes and more. 


> I suppose if we define the problem as,
> "What's the most technically efficient way to ensure that LEAs get all the
> data they need to find any Bad Guy they need to find?" that's (largely) a
> technical problem. But it assumes that the goal of the exercise is as
> stated, i.e., that LEAs' data needs are captured by: "getting them all the
> data they need..."  In fact, LEAs' data needs (in practical terms) are
> constrained by what their respective national laws authorize them to
> collect.  Hence the need to know what the laws are.  Hence the need for
> lawyers.  (Hey, don't feel so bad.  Most lawyers acknowledge that they need
> engineers...)

As I mentioned earlier, often Law Enforcement only wants 
traffic data, just because it's too costly to make reports 
of more.

..

> My earlier posting was trying to summarize what I think is the consensus of
> the list.  You, obviously, disagree (as is your right).

It makes little or no sence in a discussion to write was 
already written...

> But I think my summary is more or less an accurate
> description of what people have stated here, your
> disagreement with those statements notwithstanding. 

No problem... I think lots of people here do their best in 
their own way.

..

> >Since when is the IETF interested in the message? Or in 
> >this case specific use of the Internet?
> 
> Interesting question.  I think that the Internet community writ large has
> long been interested in various uses of the Internet.  As to the IETF's
> interest, I think that is explained in the draft...

I have to give in that I haven't read even 50% of RFC's but 
this seems one of the most =political= pieces ever to me...

> >> This leads to a consensus that on the whole facilitating the
> >> process from a technical perspective is, net-net-net, a Bad Thing, as
> >> opposed to a Good Thing.
> >
> >That's not upon IETF, IETF shouldn't be a political 
> >organization.
> 
> But it has been asked, in essence, a political question, to which it is, in
> its own techie-oriented way, crafting a political response.

I think it is =made= a political question.

..

> So all the normal concerns attendant on government trying to get private
> parties to do things -- is this legal?  who will bear the cost?  -- applies
> to making the (current) 'net more easily tappable.

Long ago solved here, costs will go to the industry. Like 
with chemical factories: One that creates a problem pays 
for it. (uh oh...)

+++chefren


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