FBI calls for mandatory key escrow; Denning on export ctrls
phil at charon.milepost.com
Thu Sep 4 15:05:54 UTC 1997
Selina F. Priestley writes...
> Let's turn this into a useful conversation: If we do not believe that getting
> a backdoor to our keys is a useful way to insure security on the network, maybe
> isn't even addressing the root issues, then
> What *are* the real issues with security on the network? How should we work to
> address these issues, both at the network and application layers? How will this
> solve the 'child porn problem'? What are the barriers involved in any proposed
The real issues are many, weighted by our varying concerns.
The 'child porn problem', as I see it, is still a strawman with regard to
the encryption issue. Large amounts of unencrypted child porn continue to
traverse the Internet that can be tracked down, and is not. I know it is
not because repeats have continuously occurred from the same sources within
the US. From what I see, law enforcement agencies like the FBI are not
really interested in kiddie porn peddlers, but instead are perhaps more
interested in large scale criminals and terrorists.
But the politicos are interested in power, and will use whatever they can
(e.g. the public's outrage over child porn) to gain more power. They will
bring out the strawman for us to beat on, too.
While the child porn problem is real, lots of people are getting things
mixed up with regard to pornography _of_ children, and pornography being
sent or displayed _to_ children. For the most part the two are unrelated
outside of common disgust. The larger real concern is the latter, and the
latter does not function unless the targets are able to decrypt the porn,
if indeed it ever was encrypted. How many children can be in the path to
obtain a decryption key that the FBI would not be able to get? In the
former case, where very few people have the decryption key, and the FBI
really would have difficulty intercepting such a key, then the numbers
involved are few, and the scale of the crime is small (that is, if the
message itself is the crime).
So, IMHO, the encryption problem is unrelated to any porn. Where they
really want to get their hands on keys and cannot is in areas where the
message itself is merely _about_ a crime, or potential crime. In other
words, terrorists and the like.
> How can we trace criminals/spam artists/hackers easily and hand them over to
> the feds w/o handing over our rights as well?
Accounting tracking. If someone originates illegal material over your
network, then with your cooperation with regard to tracking, it is possible
to track an event to a specific account.
Each ISP should keep accounting records when each account is connected on
the net and at what address. Basically, you need to know who is using each
address at what time. Filters need to block spoofing at the source. The
terminal server should let no other source addresses out but what it is
configured for, for that account. Each news and SMTP server should track
this by making sure its additions to the headers are correct and valid.
Make sure the clock is accurate.
When law enforcement comes to you with the records of data coming through
the network that originated at your location, you should be able to produce
the identity of who originated it. You obviously have to decide how you
will deal with legitimate requests for identity vs. fishing expeditions,
which many of us feel is illegal. My own policy would be that if they have
a very specific item they are working with, with all the headers intact,
then I will give them the identity of the account. Any more will require
a validated court order. The identity of the account might well be just
the credit card number of who has been paying for the service (that may well
be the only authentic identity I have for the account).
When law enforcement comes to you with a request for all your tracking data,
then you have to decide how you are dealing with that. I personally see that
as a violation of privacy, meaning I will expect a court order and will have
my lawyer verify its validity.
> If we don't have any answers to these questions, and plans for getting there,
> then we might as well quit our bitching.
We have answers. We can make up some more, if that's what's needed.
Phil Howard KA9WGN +-------------------------------------------------------+
Linux Consultant | Linux installation, configuration, administration, |
Milepost Services | monitoring, maintenance, and diagnostic services. |
phil at milepost.com +-------------------------------------------------------+
More information about the NANOG