Subject: RE: [Raven] Fly away, raven

From: Brian Rosen <[email-masked]>
Date: Fri, 29 Oct 1999 14:44:00 -0400

This debate is, of course, fairly unusual.

In general, the people who are interested in doing something come
together (in a BOF usually).  If there is sufficient interest,
a WG is formed, and work is done.  Consensus is determined by the
people who are doing the work.

In this case, 99% of the "No way" comments come from people who 
don't want to do the work.  They wish to tell me, who would do 
the work, that I can't do it, at least not here.  So what you are
saying is not, "We don't want to do this", you are saying 
"we don't want you to do this".  Pretty strange.

If you want to take a pulse on the people who are developing the 
protocols affected, you might get a different opinion than you 
would by asking the folks who are just chiming in with no 
intention of participating in the work.

Suppose we had a BOF meeting for people interested in developing
the architecture and requirements for legal intercept, and 100 
people showed up, ready to do that.  Are you saying that the 
consensus of folks on this list overrides the consensus of the 
100 people who wanted to do it?

Let's take this a bit farther.  Megaco has a pretty decent tap 
tool - you can "bridge" in a listen-only connection.  Let's say 
all of you folks decided that because it's an uncontrolled tap, 
which the LEAs could use, that we should take a vote on changing 
the Megaco protocol definition.  All the folks on the Raven list 
vote to do so.  Is this reasonable?  Is this consensus?
What about the people in the Megaco WG?

If we can, for "moral" reasons, have one group telling any other 
group in the IETF that they can't do something, where do you 
draw the line?   

Brian

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]]
> Sent: Friday, October 29, 1999 11:55 AM
> To: [email-masked]
> Subject: Re: [Raven] Fly away, raven
> 
> 
> [email-masked] (Brian Rosen) writes:
> > I believe you can state with confidence that those of
> > us who disagree with you are more aghast at your rhetoric than
> > your arguments.  Consensus is very far from "crystal clear".
> 
> All that's needed is *rough* consensus.
> 
> > I believe the majority of people looking at this issue
> > who deal with the reality of the market and the reality of
> > the law have signed off the list, understanding that the
> > noise level is way too high to get anything done.
> 
> If you're not participating, then I'd argue that you're implicitly
> agreeing with whatever result the discussion produces.
> 
> > Do not take silence for assent.  Take it for bewilderment
> > and lack of time to argue, while we do the deed anyway.
> 
> It doesn't work that way.  Lack of disagreement is, at least in the
> rough-consensus world of the IETF, identical to assent.
> 
> > Also, please, please remember.  The work is primarily to limit
> > what the tap gets you.  The tap itself is easy, and there now.
> > What we need to do is have a way to limit what the tap presents
> > to the LEA to just what the warrant says.  That we don't have
> > now.  
> 
> Nobody says that all work must go through the IETF in order to be
> standardized or validated.  If you feel the need to paint your
> hardware puce and issue your software on Mylar punch tape, feel free.
> No RFC required.
> 
> It appears to be the case that the majority on this list do not want
> to proceed with an effort to standardize tapping mechanisms, and that
> neither side of the debate is significantly affecting the other's
> position.  Is it time for a poll?
> 
> -- 
> James Carlson, System Architect                     
> <[email-masked]>
> IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 
> 781 372 8132
> Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 
> 781 372 8090
> "PPP Design and Debugging" --- 
> http://people.ne.mediaone.net/carlson/ppp
> 
> _______________________________________________
> raven mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/raven
> 

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

---

From: James Carlson <[email-masked]>
Date: 29 Oct 1999 15:30:16 -0400

> "we don't want you to do this".  Pretty strange.

I certainly can't speak for the others who might share my opinion on
establishing a tapping standard, but I can say that I haven't said,
nor do I intend to say, that you can't do this yourself.  You're free
to do anything you like.

I *am* saying that given the legal and political ambiguities -- it is
commonly understood that CALEA, at least, does not apply to ISPs, and
it is also commonly understood that different countries and regimes
have different detailed requirements (cf. chefren's continued
reference to "tapping rooms") -- and given the likelihood of a very
bad result from IETF action -- such as *NECESSARILY* weaked security
protocols that will *NECESSARILY* allow unauthorized access to the tap
points, it's unwise for the IETF to participate either by establishing
standards or helping those who do.

> intention of participating in the work.

I'm not sure I understand what your implication here might be.  Are
you saying that I'm not a developer?  That I'm not qualified to
comment?  That I wouldn't be affected by the result of any decision
made here?  If any of those are the argument, then it's rather weak.

> 100 people who wanted to do it?

No.  I'm saying that this discussion is *precisely* that gathering.
If you can find 100 people who both want to do this and can agree on
what *this* even means, then, great, have them state their case here,
build concensus around the idea, set up a BOF, and do this.

It's not sufficient to just state that you're unhappy but remaining
silent for obscure reasons.  It's not sufficient to state that you
"must" do it one way or another regardless of what the IETF chooses.
If you care about the outcome, then it's rather simple -- you must
participate.

The IESG asked for comment on the notion of establishing tapping
standards within the IETF.  That's what's going on here.

> What about the people in the Megaco WG?

The point here is not whether existing protocols may have features
that might allow tapping.  The point is whether the IETF is used to
standardize such usage.

> group in the IETF that they can't do something, where do you 

The lines being drawn here are (excluding some of the fringe for the
moment) purely technical.  We don't know how to make a mechanism that
somehow distiguishes between "bad" users and "good" users.  We want to
design protocols -- as far as technically possible -- that do not have
obvious flaws.  Therefore, as responsible designers, we choose to make
no mechanism.

For what it's worth, telling a group what it can do is exactly the
purpose of the IESG.  And that, as they say, is where I came in ...

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: Firebeard <[email-masked]>
Date: 29 Oct 1999 14:34:23 -0500

>>>>> Brian Rosen writes:

BR> Suppose we had a BOF meeting for people interested in developing
BR> the architecture and requirements for legal intercept, and 100
BR> people showed up, ready to do that.  Are you saying that the
BR> consensus of folks on this list overrides the consensus of the 100
BR> people who wanted to do it?

	Feel free to do the work.  The consensus of this list doesn't
impact whether or not the people interested in doing the work can do
the work.  It should impact whether the results of the work are
accepted as an IETF standard.  Just because you've done the work,
doesn't mean that it gets accepted.

-- 
#include <disclaimer.h>                               /* Sten Drescher */
Amendment II, Revised: A well-regulated population being necessary to
the security of a police state, the right of the Government to keep
and destroy arms shall not be infringed.

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 29 Oct 1999 12:54:16 -0700

James Carlson wrote:
	[..]
> We don't know how to make a mechanism that

This is incorrect. As brian has pointed out, "we" (the IETF) are already
developing wiretapping mechanisms. They just happen to be called
multi-pary call control, session control, etc, etc.... protocols.
Until people realize that "we choose to make no mechanism" is
fantasy heads-in-the-sand, this list is establishing a meaningless
consensus.
 
> purpose of the IESG.

We agree on that.

gja

---

From: James Carlson <[email-masked]>
Date: 29 Oct 1999 17:41:02 -0400

> multi-pary call control, session control, etc, etc.... protocols.

The distinction between these two -- developing tools for one purpose
(whether RMON, multi-party call-control, or otherwise) that might also
have another use on one hand, and explicit design of single-purpose
tapping protocols and mechanisms on the other -- is rather obvious, is
it not?

The question put this list was whether the IETF should explicitly
design for this case, rather than having hit-or-miss mechanisms that
may not necessarily serve the LEAs as they like.  For instance, a
secure mechanism to allow an N+1 caller only upon verification by the
existing N parties would -- quite obviously -- be acceptable for
multi-party call-control, but unacceptable as an LEA access mechanism.

Once again, given the likely danger of designing in intentional flaws,
and the continued and demonstrated lack of a need to do so, I still
say we must err on the side of doing nothing.

> fantasy heads-in-the-sand, this list is establishing a meaningless

That's great.  I similarly think that designing purposeful security
holes into a product is fantasy heads-in-the-sand behavior.  Thanks
for offering the parsimonious phrase for it.

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 29 Oct 1999 15:24:54 -0700

[..]
> for offering the parsimonious phrase for it.

Agreed. And that has _what_ to do with the scenario I've been
suggesting?

cheers,
gja

---

From: Sandy Harris <[email-masked]>
Date: Sat, 30 Oct 1999 16:15:43 +0000

> This debate is, of course, fairly unusual.

Yes, but then so is the notion of using designing protocols with some
design criteria which are obviously contrary to the interests of the
people communicating via those protocols.
 
> don't want to do the work.

Many of the comments are from people working on Internet security.
Since wiretaps both deny communication security to their targets and
entail various other security risks, the interest is natural. So
is the "no way" reaction.

> ... Megaco has a pretty decent tap
> the Megaco protocol definition.

If it exists solely to support tapping, take it out. If it has
other uses, redesign it or document it as a security weakness
and discuss defenses against it in your security section.
 
> group in the IETF that they can't do something, ...

The Internet Engineering Steering Group exists to provide guidance
to the IETF and its working groups. The Internet Architecture
Board has overall design responsibility for the net.

Those two groups have issued clear guidance on issues closely
related to this, in RFC 1984. I think it applies here.

Your draft-ietf-megaco-protocol-04.txt should add RFC 1984
in the "normative references" section.