From: pfarrell@netcom.com (Pat Farrell)
Date: Sun, 10 Dec 95 11:07:21 PST
To: pfarrell@netcom.com
Subject: NIST GAK meeting writeup, LONG part 3 of 3
Message-ID: <199512101904.LAA20587@netcom3.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

NIST Key Export meeting, December 5, 1995 Long version 
Part 3 of 3.

This covers the notes on agent criteria, and the 
industry presentations. 

Part 2 of three hasn't been written, it is supposed to 
address the issues related to interoperability. I 
decided it was better to get this part out than to 
wait.

Items on the criteria themselves that I think were under 
reported in my first reports:

Ed Appel: the LEA's are very interested in Criteria #5 
(two ended decryption) as they have more than 100 
international offices.

Miles Smid described a trick for meeting Criteria #5, 
if you encrypt the session key with your own public 
key, in addition to the key of your destination, and 
if you have escrowed your private key with an Escrow 
Agent, then nearly any approach meets criteria #5.

   *********
On agent criteria:
   *********

Geoff G. says that the discussions on agent criteria 
are simply a follow-on to the main criteria #3.
The criteria themselves have been spam'd to the list.
They are also available at url:
<a href="http:/www.isse.gmu.edu/~pfarrell/nist/escagent.html">

There was a lot of reactions to the SECRET clearance
requirement, which they claimed was to handle
secure investigations (e.g. FISA). This has already
been discussed on the list, so I'll skip it here.

David Lesher asked a series of questions concerning 
the requirement that the Key Escrow Entity employ a 
person with a SECRET clearance. They included: what 
agency will issue the clearance? Who will authorize 
for the BI (background investigation)? Who will pay 
for it? Who does the existing RBOC clearances? Geoff 
dodged nearly all of them. He acknowledged that "they" 
will have to pay, but made no effort to define who 
"they" are.

Geoff said that they may want legislation support for 
protecting against illegal release of keys, failure to 
release, etc.

A fair number of the agent criteria would be considered
professional business practice (no single point of
failure, dual locations, etc.) if you thought that
escrowing keys was a good thing.

  *********
User/Industry presentations

Bill Sweet of TIS

Bill gave a presentation about his CKE product, and 
how hard he is working to "find a global solution."

This is actually the same product that Bill talked 
about in September when he worked for National 
Semiconductor. It was impressive then (private keys 
are NOT escrowed, only session keys, etc.) and is 
still not approved for export.

Bill talked about "information owners," they 
ultimately decide which security systems get deployed 
"in spite of various government requirements around the 
world." He said that "if rational key escrow systems 
are not offered, or do not adequately protect their 
information, owners will use unescrowed encryption 
from whatever sources available (Germany, et al)."

Bill talked about a UK University (Royal Holloway) 
study on UK/European needs for key escrow. He said 
that there was a lot of overlap with the NIST 
criteria, but that there were criteria that were 
judged as totally unacceptable. The first and loudest 
finding was:

"the use of the scheme should provide visible benefits 
to the user."

This begs the obvious question, what 
visible benefits to the user does GAK bring?

Two other interesting findings in the study were:
- - An entity with a warrant should not be able to 
  fabricate false evidence."
- - Abuse by either side should be detectable by the 
  other.

He suggested that these criteria be added to the NIST 
list of 10.

Bill went on to look at the NIST criteria. He said, 
concerning Criteria #3 (agents certified by US 
Government or reciprocal agreement), that "this is a 
show stopper!" because:
- -- no reciprocal agreements exist today, anywhere.
- -- what about countries where justice systems are 
   different, and what about where "these agreements are 
   not desirable (e.g. Nigeria, Mexico, Saudi Arabia, 
   Argentina, Poland, etc.)?
- -- even for NATO countries, agreements will be 
   different (Germany has data privacy laws, in Greece), 
   or we may not want to be reciprocal (in Greece, the 
   government likes to bug the opposition)

He also says that Criteria #7, 64-bit keys, is 
unacceptable. CE Infosys currently sells a PCMCIA (PC 
Card) encryptor that does triple-DES at T1 speeds. TIS 
uses it, and sells it in the US. [as an aside, I was 
told that they can import and resell them, but when 
one breaks, TIS can't ship it back to Germany for 
repairs. Sigh.]

Sweet had two recommendations:
- -- develop a tiered crypto policy, with hardware and 
   software under differing levels of rules,
- -- allow a pilot project, where TIS can sell VPN 
   (virtual private networks) using strong encryption. A 
   VPN is the use of the Internet as a private network 
   for a corporation by adding appropriate firewalls, 
   encryption, etc.


It seems to me that while TIS' CKE doesn't meet the 
criteria, it could be made to, with a few changes.
They've have to change the design to allow GAK
for any one target. (Criteria #5) This would mean
for generating one DRF (ie., LEEF) for each recipient 
as well as for the sender (as opposed to just for 
the sender) The neat thing about CKE is that each 
LEEF holds only the session key -- so you never 
give away your private key. (I think the govenment
really expects that we'll be willing to 
escrow our private keys. Fat chance!)

But this is a bit of a catch 22, because 
to follow all the criteria, you can't stop there.

- -- For each encryption, you generate a DRF for the 
   sender and each recipient

- -- For each DRF generated, you must have and check 
   a certificate chain for the chosen DRC and 
   refuse to encrypt unless all recipients and 
   the sender have validly certified (ie., USGovt
   approved) DRC public keys.

- -- Each receiving application must refuse to 
   decrypt unless every other recipient and 
   the sender have validly certified DRC
   public keys. This gets into the interoperability
   issues that I need to write up...

- -- I don't know how they can meet the revised #6. It
   seems to be designed specifically to break CKE.

To get govie approval, each DRC needs to meet all the
key escrow agent entity criteria. I'm really not at
all convinced that it is actually practical. This is
sad, because CKE is obviously designed with the spirit
of the government at heart, with just some modifications
to make it marketable. Guess TIS needs an Ireland office 
too.


Ken Mendelson of TIS

Ken gave a solid presentation describing how all of 
the Government's need for data about key escrow agents 
could be met with a commercial "vendor registration" 
approach instead of a Government mandated 
"certification" scheme. This would be in keeping with 
the current "spend less money, have less government 
bureaucratic rules" political climate. I have copies 
of his slides, I'd rather not type them in. With any 
luck, he'll put them up on the TIS web site url: 
http://www.tis.com

Dorothy Denning of Georgetown University

Dorothy Denning gave a presentation on an article that 
will be published in the March 96 Communications of 
the ACM. It analyzes currently available products (and 
vapor products) and sees how well they meet Criteria 
#5. It says that eight of the sixteen approaches that 
she surveyed currently meet Criteria #5. She lists her 
web page as http://www.cosc.georgetown.edu/~denning, 
but as of Sunday 12/10, the text is not available.

Melanie Janin, US Council for International Business

Ms. Janin's speech presented the US Council for 
International Business' comments on GAK. They are a NY 
based trade group, representing 300 clients. They 
don't like GAK. She called for a coherent policy on 
all encryption. Major topics in the presentation 
include:
- - free choice
- - open to the public
- - international acceptance
- - flexibility of implementation
- - User key management
- - Key escrow (where they "embrace key escrow as one 
  possible method of managing encryption keys.")
- - Liability

Ed Scheidt, Tecsec

Presented both comments on the criteria and his 
company's VEIL and Export VEIL Version 2.0 products. 
He raised a number of points, including:
- - how do we protect our commercial information unless 
  we have the best cryptography?
- - we need "constructive key management technology" to 
  manage keys, key splits, and different algorithms for 
  extended data separation.
- - solution must address issues such as international 
  trust in a key escrow.

He said that his "Export VEIL 2.0" product meets "the 
intent of 11/95 export criteria today."

Daniel Weitzner of CDT

Mr. Weitzner agreed to shorten his presentation so 
that he could yield some time to VTW.

He opened by pointing out that while the schedule had 
both him and Jerry Berman were supposed to talk, Jerry 
was too busy to make the meeting. "Jerry is out 
defending pornographers, so I'll be here defending 
terrorists."

I expect that his text will be on CDT's webpage, url: 
http://www.cdt.org. I'll just enter the key points.

The first thing he said is that "this is the wrong 
forum" and that "the [NIST] process will not work." He 
proposed a open, privately sponsored forum to develop 
alternatives that will work.

"The NIST proposal will not provide adequate security, 
privacy, promote secure communications worldwide, or 
guarantee user privacy." Major issues are:
- - Inadequate security
- - No viable policy framework for the long-term
- - Hinders the deployment of globally interoperable 
  secure systems
- - not necessarily voluntary
- - not viable in the marketplace
- - no constitutional privacy protections
- - will not meet the needs of law enforcement, since it 
  will "not deny criminals or terrorists access to 
  strong encryption, the stated objective of the 
  policy."

Shaber Safdar, Voters Telecommunication Watch

Described the results of an Internet-based, non-
scientific survey that the VTW recently made. Not 
surprisingly, those who replied were overwhelmingly 
against the NIST proposal. I don't have the slides, 
but VTW has a website with most of their information. 
The url is http://www.vtw.org

There were 26 respondents to the survey. 24 out of 26 
said that they would never buy products with law 
enforcement access. 16 out of 24 are already using 
security products.

He described a Technology Pledge that VTW is 
presenting to politicians (available at url: 
http://www.vtw.org/pledge/) and stated that Rep. 
Ronald Wyden (D-OR) signed the pledge with pro-
freedom, pro-market answers.

David Sobol, EPIC

As expected, EPIC doesn't like much about the NIST 
proposal. Their comments are on their web page, url:
http://www.epic.org/crypto/EPIC_Statement.html

A key statement is "Given the reality that users are 
unlikely to adopt key escrow systems on a voluntary 
basis, we believe that the current policy will result 
in the eventual prohibition of non-escrowed products. 
Indeed, documents released to EPIC under the Freedom 
of Information Act (FOIA) reveal that NSA and FBI 
concluded nearly three years ago that

	'Technological solutions such as they are, will 
     only work if they are incorporated into all 
     encryption products.'"

Major points 
- --Public comment is frequently solicited but never 
  heeded.
- --Relevant information has not been released. 
- --The proposal conceals the attempt to expand 
  wiretapping capability 

As a result, EPIC proposes the following Policy 
Recommendations

- --Relax export controls on encryption and permit the 
  free flow of encryption products across national 
  borders
- --Withdraw FIPS 185 (the Clipper standard for voice, 
  fax,...  and low speed data networks in the 
  federal government)
- --Remove "cryptology" from items that may be 
  classified ...  under executive order
- --Do not fund the Telephone Carrier Compliance Program         
  (the "Digital Telephony" proposal)
- --Do not permit the use of classified algorithms for         
  public networks
- --Examine the activities of the National Security 
  Agency ... since passage of the Computer Security 
  Act of 1987.

NOTE: during Mr. Sobel's discussion, a FBI 
representative sitting at the head table said  that 
the issues addressed by key escrow are "not just 
wiretapping, they include search and seizure of all 
stored media." I was not able to identify the person. 
He was sitting at Ed Appel's seat, but did not have a 
namecard. No one sitting near me recognized him 
either.

Padgett Petersen, Lockheed Martin

Noted Internet personality, Padgett Petersen took a 
rarely held position, he spoke as a Security officer 
of Lockheed Martin, rather than speaking as a private 
net-citizen.

He said that "these criteria are acceptable and can be 
made to work." He also said that "without US 
agreements, there is no reason to be concerned with 
export." Lockheed Martin was looking forward to 
participating in using and buying the escrowed 
products that will hit the market as a result of this 
process.

Robert Hollyman, Business Software Alliance

Mr. Hollyman said that "the facts are clear, companies 
are unanimous against" the NIST proposal. His members 
agree that:
- - security is critical
- - 40 bit is not viable
- - the 1992 government review requires a change in 
   policy.

He recommended:
- -- immediate approval of DES or equal strength 
   alternative for export.
- -- encourage companies to build encryption software by 
   submitting code to NIST (under non-disclosure) for 
   review
- -- add two bits ever three years to allowable key 
   lengths in recognition of Moore's law. He called this 
   a COCA allowance (cost of cracking algorithms).
- -- removal of restrictions on interoperability because 
   they are artificial and antithetical to the Global 
   Information Infrastructure.

He stated that the current criteria are vague, and 
will take years for approval. Yet he notes that in 
industry, the average life cycle of software is 18 
months.

Alex McIntosh, PC Security

PC Security sells key management systems. Shell is a 
customer. He addresses a couple of areas that his 
commercial customers ask. 

The first question is "why encrypt?" He said that the 
answer is to protect confidential data. These data 
include email, PC files, and archival data. 

This leads to the obvious question, why use key 
management? The two separate answers are to have  
operational backup and to allow compliance with 
internal and external law enforcement.

He said that he has a surprise for the NIST folks 
concerning key escrow agents. The corporate customer 
is the key escrow agent.

Other key observations:
- -- Companies, such as Shell, often do business in 
   countries where they can not trust the government.
- -- Shell handles over a million email messages a day. 
   This defines engineering requirements for any system 
   to meet.
- -- Liability is a huge issue, and the amounts are 
   huge. Geologic information, market strategies, etc. 
   are worth staggering amounts of money. The "US 
   Government can NOT cover Shell's liabilities."

Doug Miller, Software Publishers Association

Mr. Miller said that his members need immediate relief 
from the current encryption export policies. "our 
members are poised, but cannot leap, because of the 
barriers that U.S. cryptographic policy continues to 
impose." He wants to be able to export 56-bit DES. His 
position paper says, "we believe the discussion should 
also include assessment of the exportability of 
products employing the DES algorithm. DES-strength 
(56-bit) products can compete with 179 foreign 
products (80 of which are software products) that 
employ DES. Liberalization of the export restrictions 
of software with encryption capabilities is essential 
if U.S. companies are to compete with strong, widely 
available non-escrowed products."

Viktor Hampel, Hampel Consulting

Proposed "a 'Consumer Protection Act for Digital 
Products' to support electronic commerce and to 
control the increasing abuse and lack of security on 
the national information highways." A copy can be 
obtained from Hampel Consulting, 1515 Jefferson Davis 
Highway, Crystal Square Suite 913, Arlington VA 22202-
3312.

In his remarks, Mr. Hampel said that trust is 
important between business. Business worries about 
issues as varied as what accountability is in the 
system and how much is the per minute interest on a 
billion dollar money transfer? These cause business to 
need solutions that NIST hasn't raised.

He recommended that a public key infrastructure be 
included into the Uniform Commercial Code.

Closing comments.

Mike Nelson noted that the meeting had some time for 
floor questions.

He was asked what is the timeframe for finishing the 
process. He danced, saying that promising a fixed date 
for policy decisions is bad for your career, but 
thought it would be done in a couple of months.

Someone asked about the "Personal Use" export process 
(the one that will allow you to export PGP on a laptop 
computer for personal use, and that was promised for 
"in a couple of weeks" at the September NIST meeting). 
They said that it is about to go to the Federal 
Register, and should be available within weeks.

Nelson was asked about foreign escrow agents. He said 
that "if there exists bilateral diplomatic agreements, 
then the US will allow specification of Foreign Escrow 
agents." [Of course, no such agreements exist now.]

Ed Appel of the White House said that the intent is to 
make export "as easy as 40-bit" is under the existing 
policies. The existing export policies will continue.

He also said "so far, we are only controlling export" 
and that "the government has very strong cryptography 
available to them, so they are not worried about 
export." He said they hope to control export in two 
ways, first by applying the combined purchasing power 
of the US Government to encourage the market, and by 
controlling export.

	 *********

After the meeting closed, I invited both Mike Nelson 
and Ed Appel to the next DC Cypherpunks meeting. 
Somehow I expect it when they declined.

     ********
A note on quoting within this document: I did not take a 
tape recorder to the meeting. Words in quotes were taken
from either my hardcopy of handouts, words in documents
on cited webpages, or from my noted. I tried hard to 
keep the words accurate and in context. There may be some
cases where my quotes are incorrect. If I've misquoted
anyone, it is not delibrate, and if told, I'll post
corrections.

Pat

Copyright (c) 1995, Pat Farrell.
Permission granted to electronically redistribute, provided
it is transmitted in the whole and unaltered.

-----BEGIN PGP SIGNATURE-----
Version: 2.6

iQCVAwUBMMsugLCsmOInW9opAQGWSAP/QC3Xja8kE56XGximmiiIVEv3ihJI1uY5
2eWZSVUGOxATc3jbwtLS5bqmkDnSXhQaaD6Slk/zA9IGlNhzi4tMV1xsrKwj4l4d
0KefEWOTinVze+6SQFsIVizGb9WzRaTrGwCV9RY7RRbC0dYa+cb21JXvlZOxYk/Q
wGfkSY5/H0Y=
=hJvT
-----END PGP SIGNATURE-----



Pat Farrell      grad student        http://www.isse.gmu.edu/students/pfarrell
Infor. Systems and Software Engineering, George Mason University, Fairfax, VA
PGP key available via finger or request           #include standard.disclaimer