From: Michael H. Warfield (mhw_at_wittsend.com)
Date: Thu Oct 31 2002 - 22:53:22 CET
On Thu, Oct 31, 2002 at 11:03:33AM -0800, seberino_at_spawar.navy.mil wrote:
> Thanks for the info. Doesn't IPv6 require
> IPsec??? If so, then how can governments play games
Yes. To be fully IPv6 compliant, IPSec is required. The IETF did
that intentionally, with malice aforthought.
> with restricting distribution of it? It would be
That's the whole point. By making it a required feature, you
make life a lot tougher on those restrictions.
> a little silly since the entire Internet would be
> using crypto in all Internet traffic.
Hmmm... Not quite. IPv6 requires that IPSec be supported. It
doesn't require that it be used.
Certain things (and I find this quite disturbing) such as OSPF6
have removed much of their security and authentication and are going to
rely on the IPSec AH facilities in IPv6 instead for authentication. So
if you are going to use OSPF6 on IPv6 then you will have to use IPSec
between those systems. I really don't like that...
> So if US government tried to clamp down on crypto
> exports would that mean that technically fetchmail,
> openssl, gpg, etc. servers would all have to be
> careful?? Seems like that would be very damaging
> to economy and unrealistic. I hope it never happens.
That's exactly the point. Even now, more than ever, any
effort to clamp down on exports would raise such a din in the business
world and open source world that it would threaten to become a
category 5 shitstorm on any politician supporting it. We've already
seen some evidence of that in the aftermath of 9/11 and in the ongoing
efforts by businesses to get the regulations relaxed even further.
Actually, it's better than that... The regulations never were
enforcible. Phil Zimmerman and PGP are a case study in that. The US
government always knew those regulations were unenforcible. They
depended on FUD, Fear Uncertainty and Doubt, to be their enforcers.
Some of this has been confirmed by our Washington DC crypto lawyer, but
even the vagueness and ambiguities in the regulations were intentional.
By making those regs unclear, companies would "over regulate" themselves
"just to be sure, when in doubt" (and there was deliberately lots of doubt
sewn in there).
They couldn't "prosecute" Phil because of the danger that they
would loose and, in the process, loose that FUD edge along with all of
their regulations. So they tried to persecute him into bankrupcy. That
failed. It not only failed, it demonstrated the futility of the effort.
As far as getting crypto "rolled back" out of a product, the
last incident I recall was something better than a decade ago with the
old NCSA HTTP server. The story at the time was that the NSA forced
them to remove the SSL code from that server by threatening the
university's govenment funding. They didn't even invoke the regulations
then.
Later, faced with the immenant threat of having all their regulations
tossed out because other people, such as John Gilmore and Dan Bernstien,
pushed the matters in court, they tried to do an end-around by shifting
the ITAR regulations to the EAR regulations under a different government
department. That just delayed the inevitable.
They were then faced with the open prospect of a judge who said
that parts of the regulations were a first amendment infringement and
that they could not be separated out from the regulations without
rewriting the regulations (which he refused to do) and was, again, poised
to throw out the whole kit kat and kabodle. This is when they removed
the export restrictions on the Open Source sources. That pulled the
fangs of all the free speech arguements while preserving their ability
to regulate the closed source commercial products.
The next relaxation, in the form of a clarification, removed
the restrictions on the binaries which are based on the open source
sources, allowing binary distributions.
Following that was a further relaxation which allowed for freer
distribution of binaries and sources on distribution media such as CDs
(the original changes helped everything but network distribution more
than anything else).
What was amusing (for me) in this last relaxation was that I had
the news and informed our other staff cryptographers and engineers and
our corporate lawyers before our Washington crypto lawyer had a chance
to do it. :-)
Now the shoe is on the other foot and the fear is on the other side.
If they reinstate crypto restrictions on open source software, they risk
an immenant and real threat that ALL of their regulations will be thrown
out in a court case. That, they can not risk. It's that threat (the
loss of the closed source proprietary restrictions) that keeps them at
bay much better than anything else could. So they live with this
to keep what they still have.
Now, even my buddies on the FBI and NIPC have to use PGP.
If they want encrypted, confidential, information from Internet
Security Systems, we send it to them PGP encrypted. The irony is
delightful. But this is a case where they don't call the shots anymore.
They wanted us (members of NIPC and INFRAGARD) to use some proprietary
stuff and a number of us told them to go stick it. We use PGP in
FIRST (Forum of Incident Reaction Security Teams, <www.first.org>) and
there was no reason for us to use TWO different methods and they
wanted our participation. So what they tried to persecute into
oblivion now becomes (reluctantly) one of their communications methods.
It's almost ironic that the FreeSwan group actually acts in
compliance with the original intent of the US Government. The government's
goal was to use FUD to scare organizations into regulating themselves
much tighter than the government could ever get away with doing itself.
The FreeSwan policies are a classic example of how well the US government
succeeded at that even to this day, even outside of it's jurisdiction.
Ya just gotta love it...
> Chris
>
>
> On Thu, Oct 31, 2002 at 09:19:15AM -0500, Michael H. Warfield wrote:
> > On Wed, Oct 30, 2002 at 11:32:31PM -0500, Ken Bantoft wrote:
> >
> > > On Wed, 30 Oct 2002 seberino_at_spawar.navy.mil wrote:
> >
> > > > I heard somewhere that FreeSwan is going into
> > > > 2.5.x kernel because of new US laws that allow
> > > > this? Is this true?
> > > >
> > > > Can someone please elaborate on current
> > > > US export laws regarding crypto and freeswan?
> >
> >
> > > FreeS/WAN is not, and probably will never go into the mainstream kernel.
> > > The project sponsor (John Gilmour) has mandated from day one that 0 lines
> > > of code from US citizens/residents be allowed into the project. Linus is
> > > a US citizen and/or resident. David Miller (kernel developer, RedHat) has
> > > said he'd never put something into the kernel that he couldn't touch.
> > > Both sides have very valid points, and thus are in a permadent state of
> > > dead-lock.
> >
> > > Linus merged a variant of an earlier fork of FreeS/WAN, mixed in with some
> > > code from the USAGI project (IPv6 for linux, which includes ipsec), and
> > > some new code to glue it all together. So there is ipsec support in the
> > > kernel. But no userland tools, config files, etc. That's all extra, and
> > > not part of the kernel.
> >
> > Which means that FreeSwan will eventually be redundant. At least
> > I can work on the crypto code in the kernel.
> >
> > > Now, for the 2nd part of your question.
> >
> > > IANAL, however this is my understanding of the current situation.
> >
> > > The US "relaxed" regulations by a government declaration. This is *not* a
> > > law, and thus can be revoked at any time by either the house, the senate
> >
> > This was always true both ways and applies to all countries.
> > France relaxed it's laws but can equally turn around and tighten them.
> > China "technically" prohibits the possesion of cryptography and yet
> > I listened to several officials from the Ministry of Information Industry,
> > in person (through an interpreter) speak of the need for strong privacy
> > and strong cryptography to promote E-Commerce. They are "permitting"
> > crypto but can clamp down in an instant. The Brits keep dragging up
> > ideas for accessing people's keys and crypto that are absolutely draconian.
> >
> > > or the President. As such, you can export products with crypto outside of
> > > the US freely, until the government changes it's mind (which will probably
> >
> > Until ANY government (including Canada) changes their mind.
> >
> > > happen shortly after the US goes into it's next war. I mean hey, we don't
> >
> > Sorry you haven't been keeping up with current news and events.
> > The subject came up just after 9/11 and it was explicitly decided in Congress
> > that it was more in the interest of the US to promote strong cryptography
> > and protect our own equities and that restricting cryptography exports
> > did nothing to aid the US. So the idea of restablishing export restrictions
> > was not only shot down but the regulations were even FURTHER relaxed.
> > Further relaxed TWICE after.
> >
> > > want to give <insert country here> access to encryption while we're at war
> > > with them, right? <insert Homeland Security and War on Terrorist stuff
> > > here>)
> >
> > Gee... What rock were you hiding under when this came up and
> > was shot down in congress?
> >
> > How bout all that discussion up there in Canada about "lawfull
> > access" and all? Pretty scary stuff... Makes the Patriot Act look
> > down right tame.
> >
> > Freeh still keeps making noises like this but he got the boot
> > and ain't coming back. From the sounds of the reactions to his last
> > appearance in front of Congress (just recently) he doesn't seem to
> > have much influence or sympathy on the subject.
> >
> > > Therefore, if/when the government revokes the declaration, Linus would
> > > have to pull out all of the crypto code, or cease to distribute the Linux
> > > kernel.
> >
> > Bullshit. Get a clue. The best way to prevent that is to go
> > balls to the wall and get crypto in everything. You can't pull it back
> > once it's out there. Crypto has been on kernel.org for a couple of
> > years now. All the cryptoapi and loopaes and kerneli stuff has been
> > hosted there.
> >
> > They couldn't stop pgp when they had ITAR and then EAR in full
> > force. They didn't stop me from assisting Tatu with ssh. They didn't
> > stop me from doing the SSL stuff in fetchmail and Eric posting it on his
> > site here in the US. The FUD on this subject is enough to do Microsoft
> > proud.
> >
> > > This isn't exactly ideal for anyone at the moment, but it's 2.5 stuff, so
> > > won't be considered mainstream for another 6 months at the earliest.
> > > Hopefully some of the stuff will be sorted out by then, but I won't be
> > > holding my breath.
> >
> >
> > > --
> > > Ken Bantoft The Unoffical FreeS/WAN Site:
> > > ken_at_freeswan.ca http://www.freeswan.ca
> > > PGP Key: finger ken_at_bantoft.org
> > > "It is dangerous to be right when the government is wrong."
> > > -- Voltaire
> >
> > Mike
> > --
> > Michael H. Warfield | (770) 985-6132 | mhw_at_WittsEnd.com
> > /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
> > NIC whois: MHW9 | An optimist believes we live in the best of all
> > PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
>
>
>
> --
> _______________________________________
>
> Dr. Christian Seberino
> SPAWAR Systems Center San Diego
> Code 2363
> 49590 Lassing Road, Room A339
> San Diego, CA 92152-6147
> U.S.A.
>
> Phone: (619) 553-7940
> Fax: (619) 553-1269
> Email: seberino_at_spawar.navy.mil
> _______________________________________
> _______________________________________________
> Users mailing list
> Users_at_lists.freeswan.org
> http://lists.freeswan.org/mailman/listinfo/users
-- Michael H. Warfield | (770) 985-6132 | mhw_at_WittsEnd.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
_______________________________________________
Users mailing list
Users_at_lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.5 : Sat Nov 02 2002 - 05:20:34 CET