Subject: RE: [Raven] Fly away, raven

From: Brian Rosen <[email-masked]>
Date: Mon, 1 Nov 1999 11:57:20 -0500

> > 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.
Sure, but the same could be said of anything supporting billing.

C'mon, we live in the real world, and we sometimes have to
support things that aren't "nice".  Legal Intercept is a law,
a very old law.  It may be that it should be abolished.  Talk to 
your congressperson.  Until the law changes, we (vendors and
carriers) are required to meet its terms.  The issue doesn't 
rise to the level where civil disobedience is appropriate.

...snip... 
> > In this case, 99% of the "No way" comments come from people who
> > 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.
Like any other protocol, we would have to document the security risks.  
If you want to help the effort, you are welcome.  Interest is one thing, 
denying me the ability to do something that needs to be done, and I want 
to do, is another.  I didn't see you in the Megaco work when we 
discussed security and did what we thought was appropriate.

> > ... 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.
> 
> 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.
It exists to support conferences.  It is no more of a security hole 
than multicast is.  It may deserve some attention in the security 
section, but by that argument, we had better go back and look at a 
lot of protocols.  
  
...snip...
> Those two groups have issued clear guidance on issues closely
> related to this, in RFC 1984. I think it applies here.
No denying that IAB and IESG have advisory roles here, that is the 
purpose of the debate.  They should, as I have admonished you, 
be very careful in laying down an edict that a group of people 
who want to do something, even if it is repugnant, can't do it.  
This is NOT to suggest that there are no circumstances where it 
would be appropriate; I just don't think this is one of them.

> Your draft-ietf-megaco-protocol-04.txt should add RFC 1984
> in the "normative references" section.
RFC1984 discusses encryption.  Megaco, the protocol, uses IPSEC.
That is sufficient.  RFC1984 doesn't discuss anything except strong 
encryption.  It is not relevant to this discussion except in the 
observation that if you use strong encryption, intercept doesn't 
get you much.  This is new territory.

Brian

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

---

From: Sandy Harris <[email-masked]>
Date: Mon, 01 Nov 1999 21:52:30 +0000

> Sure, but the same could be said of anything supporting billing.

Touche.

> your congressperson.

Not a particularly useful reply to someone with a .ca address.

I've been trying not to get offended by the various US-centric
lines here, but after a while it does become rather annoying.

[snip]

> That is sufficient.

It is likely sufficient for the IP part of the network, but
since it is not end-to-end, it is insufficient to protect the
communication.

> RFC1984 doesn't discuss anything except strong

From the RFC:

   The IAB and IESG are therefore disturbed to note that various
   governments have actual or proposed policies on access to
   cryptographic technology that either:

   (a) ...
   (b) restrict commercial and private users to weak and inadequate
       mechanisms such as short cryptographic keys; and/or
   (c) mandate that private decryption keys should be in the hands of
       the government or of some other third party; and/or
   (d) ...

Any CALEA-like law for VoIP is a clear violation of this since it
is clearly an attempt to "restrict ... users to weak and inadequate
mechanisms" by preventing vendors from offerring strong end-to-end
encryption without escrowed keys.

The fact that various gov'ts have successfully restricted encryption
on voice networks does not change the policy expressed in the RFC.

   We believe that such policies are against the interests of consumers
   and the business community, are largely irrelevant to issues of
   military security, and provide only a marginal or illusory benefit to
   law enforcement agencies, as discussed below.

   The IAB and IESG would like to encourage policies that allow ready
   access to uniform strong cryptographic technology for all Internet
   users in all countries.

I'm inclined to think "all Internet users in all countries" includes
anyone doing VoIP.