1998-09-07 - (fwd) Re: KRAP is at it in the IETF

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: cypherpunks@cyberpass.net
Message Hash: ff72f5253a52959639b608e00793aa2a8c842cdd0a571d4887d044c115e1c6c9
Message ID: <199809072253.XAA08953@server.eternity.org>
Reply To: N/A
UTC Datetime: 1998-09-07 23:05:47 UTC
Raw Date: Tue, 8 Sep 1998 07:05:47 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Tue, 8 Sep 1998 07:05:47 +0800
To: cypherpunks@cyberpass.net
Subject: (fwd) Re: KRAP is at it in the IETF
Message-ID: <199809072253.XAA08953@server.eternity.org>
MIME-Version: 1.0
Content-Type: text/plain




A GAKker breaks cover on dbs list as a result of William Geigers heads
up on the issue... The GAK apologists are very thin on the ground in
public discussion forums generally, so it is nice to see the odd one
speak up.  Seems like they are too busy taking government handouts to
implement KRAP to actually own up to their misdeeds in public,
generally.

Adam

======================================================================
From: "Todd S. Glassey" <TSGman@earthlink.net>
To: "William H. Geiger III" <whgiii@invweb.net>, <dbs@philodox.com>
Cc: <tom_markham@securecomputing.com>, "JeffreySchiller" <jis@mit.edu>,
	"MarcusLeech" <mlecch@nortel.ca>,
	"Robert G. Moskowitz" <rgm@icsa.net>, <tytso@mit.edu>
Subject: RE: KRAP is at it in the IETF
Date: Mon, 7 Sep 1998 13:38:50 -0700

William,
Let me start with the disclaimer since I am going to vehemently disagree
with you - These are my own opinions and in no way reflect my companies or
our clients Opinions, etc. etc. etc. -

So William - IMHO, you are missing the point totally. The IETF is an
A-Political Organization investing in the development of technical standards
to accomplish various networking services. As to the issue of Politic vs.
Technology, by its actions alone, KRAP's demonstrated agenda with the IETF
is purely technical and whether it is in furtherance of its external
political agenda is really irrelevant to the IETF as and its established
process as a whole.

>From my vantage point, the real issue herein is your personal/moral standing
with the dissolving of anonymity through Key Recovery and Government's
ability to look at data that flows over a network. Remember also that it was
the Government that was the primary subsidizer of said same network and
everything that evolved the old 56k ARPANET into what the Public Internet is
today.

As another side issue, the other potentially-viable argument is that
ISAKMP/IKE is so far along in its process of becoming a standard, that
adding a late draft impedes the value of the work already done - Essentially
that these folks  (KRAP) have essentially slipped a whammy onto the stack.
Is it your view that this implies that because of this later posting that
the material will be exempt from the general scrutiny that the previous
components of ISAKMP/IKE have been through - I don't think so... This crowd
loves to do the Pit-Bull thang and shred the submitted concepts to glean the
technical truth therein. If this is the issue then the answer is to work
within the existing framework and to submit a public motion to the WG to
freeze the ISAKMP last call efforts so that they exclude the new draft until
such time as it (the GAK extensions) can undergo further scrutiny.

As to the issue of the addition itself being out of line because of its late
entrance into the standards arena relative to the last call and all that-
Again, I disagree as to what and how - There are numerous "standard
processes" in place that allow for this as well and that here in the real
world, use of this ability is a very common practice. Look for instance at
what happened to the last TAX REFORM effort with the addition of Senator
Moyniham's SS1706 Rider, or as another example look at what congress as a
whole did with the HIPAA legislation (http://www.hcfa.gov/regs/hipaacer.htm)
and its embedded "legal penalties" for unauthorized  disclosure of health
data. Since this case is specific to the bulk distribution of data, it
really applies directly to IT Directors and their staff. heck, imagine that
your insurance Co.'s or hospital's  IT folks could actually go to jail by
the statute set here. Again here we are at the bottom line and if this is
the thing you are objecting too then you need to object to the process not
the event itself.

As to the perversion commentary specifically... perversion is a moral issue
and is not addressed by the IETF rules (RFC2026 in particular). My
suggestion is that if you feel this is a problem that you address it at the
POISSON WG level rather than in IPSEC or PKIX since it is a process problem,
and that under the currently in-place operating rules, this thing, the
filing of a new proposed component of the ISAKMP protocol is OK to do.

- ---

Don't get me wrong, as it happens I too believe that Key Recovery is futile
effort for the government, not because it doesn't have a need for this type
of capability, but because they didn't act fast enough and the "cat is
already out of the bag". So any efforts to pull this one off will most
likely be futile and will definitely not be cost effective for normal
ECommerce operations let alone personal communications. BTW - The reality in
the Intelligence Community World is that for the surveillance of the
big-league terrorists, dope dealers, and the like, key recovery is useless
since because they are so well funded and their access to technologies is
such that they (the bad guys) can and will employ advanced technologies to
get around whatever the NSA/DSIA/DoC/DoJ put in place to thwart them. As an
example of this the Leopard's (sort of the Bolivian Govt.'s DEA Field
Agents, et al.) found that when they attacked the labs of the Median Cartel
they were out gunned and technologically overpowered to the point that
without the US Military intervention they would have no possibility of
thwarting these activities. Draw your own conclusions.

As a point of social commentary, I understand and hear your point, but if
this kind of process "invasion" as you have put it was such an issue then
how come there was so little push back was done against the "Communications
Assistance for Law Enforcement Act" (CALEA). I think that as a whole the
people against the KRAP initiatives are there because of the cost and
overhead issues, not the personal freedom ones. Thus it becomes a business
issue and not a human one.

The world is changing into a global society and the rules about personal
freedom are evolving with it... Not everyone is going to like them but the
facts are what they are and  IMHO - personally I wonder more how some local
constituency would respond to the invasion of their personal privacy when
some "pervert terrorist" parks a recently acquired nuke or Bio-toxic Weapon
from the now defunct Russian Arsenal in their backyard and pushes the #$%^&*
button. If losing absolute anonymity is the cost of better safeguarding
oneself and family from threats like these, what the heck. Its a very small
cost to pay.

My personal feeling is that since I have made the decision to live in and
work with modern society as a whole, that I must follow the edicts that
evolving technologies and social values/morals put in place by and for us as
a whole. Otherwise our choice is real simple - If you don't like the rules,
then don't play the game. Move out to the backwoods and stay out of society
as a whole.

I don't mean to be a putz by this, but come on... "a perversion". This isn't
the place for that kind of morality issue!.

Todd

> -----Original Message-----
> From: dbs@philodox.com [mailto:dbs@philodox.com]On Behalf Of William H.
> Geiger III
> Sent: Monday, September 07, 1998 1:24 AM
> To: dbs@philodox.com
> Subject: KRAP is at it in the IETF
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
> Hello,
>
> It has come to my attention that the KRAP (key recovery alliance program)
> has submitted an I-D (internet draft) to the IETF for adding GAK
> (government access to keys) to the IPSEC protocols:
>
> ftp://ftp.ietf.org/internet-drafts/draft-rfced-exp-markham-00.txt
>
> ISAKMP Key Recovery Extensions
> <draft-rfced-exp-markham-00.txt>
>
> 7. AUTHOR INFORMATION
>
>    Tom Markham
>    Secure Computing Corp
>    2675 Long Lake Road
>    Roseville, MN 55113   USA
>
>    Phone: 651.628.2754,    Fax:   651.628.2701
>    EMail: tom_markham@securecomputing.com
>
>
> I consider this a perversion of the standards process of the IETF to
> advance a political agenda which must be stopped at all cost.
>
> Below are the e-mail addresses of some people that you should write
> (politely) expressing your objections to any such additions to the
> protocols:
>
> IPSEC Chairs:
>
> Theodore Ts'o <tytso@mit.edu>
> Robert Moskowitz <rgm@icsa.net>
>
> Security Area Directors:
>
> Jeffrey Schiller <jis@mit.edu>
> Marcus Leech <mlecch@nortel.ca>
>
> As I mentioned before, be polite. These people are not the ones proposing
> GAK be added to the IPSEC protocols. They have put a lot of time and
> effort in forwarding the cause for strong encryption. They should be made
> aware of the communities objections to these attempts by KRAP.
>
> Thanks,
>
> - --
> - ---------------------------------------------------------------
> William H. Geiger III  http://www.openpgp.net
> Geiger Consulting    Cooking With Warp 4.0
>
> Author of E-Secure - PGP Front End for MR/2 Ice
> PGP & MR/2 the only way for secure e-mail.
> OS/2 PGP 5.0 at: http://www.openpgp.net/pgp.html
> - ---------------------------------------------------------------
>
> Tag-O-Matic: It's OS/2, Jim, but not OS/2 as we know it.
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3a-sha1
> Charset: cp850
> Comment: Registered_User_E-Secure_v1.1b1_ES000000
>
> iQCVAwUBNfOVk49Co1n+aLhhAQFJwwP+O4vrZVKFpOG8vCHFwbDuPIv/99AhBnKF
> RK/Ikc5y2gGKq9hfxkTb4o77YUrDaEGkYUPHk+ZC57Oag0Lu1v6W1EAbQ5T4RpzH
> JWYXOonQmbqw5rH0h6brzqrH3ep9Ej9DR0gv4mGgIfSNlJSUu6TWO5ZHXKWiE4yy
> 5flH0Ngg/TI=
> =EzNL
> -----END PGP SIGNATURE-----
>
> Tag-O-Matic: Speed Kills - Use Windows!
>
>
>
------- End of forwarded message -------





Thread