NIST GAK export meeting, Long version part 1

["Pat Farrell" <pfarrell@netcom.com>]

NIST Key Export meeting, December 5, 1995 Long version, Part 1 of N
This covers the criteria, except interoperability.

(To keep TCMay's prediction from becoming true, I'll put this out in parts) 


This really needs a hypertext media. I'll build one for html page. Please
bear with me on this, pure ASCII mail version.
This is a write-up of stuff I left out of the summary.
I'll merge them together on my nistpage, probably Friday.
You've already seen the short write up.

There is a fair amount of information on the NIST web server. Use url:
< http://csrc.ncsl.nist.gov/keyescrow/>

As David Lesher noted, one of the most significant things was obvious in
the parking lot.  Unlike September's meeting, this time it was empty.
Inside the hall, it was obvious that no one came. It was packed in
September, and now, entire rows were empty. I'm bad at guessing numbers,
but its easy  to guess that only 1/3 as many people showed. Maybe less.

>The meeting was hosted by Ed Roback of NIST,

The meeting was in general a repeat of September's meeting, and similar
meetings that have been going on for years. Both sides talk past each
other. I think this has degenerated into a parallel with the abortion
debate. There is no common ground.


>He said that they have studied the encryption that is supposed to be widely available on the Internet.
>He said that viewed by crypto experts, not much is very good. He mentioned "two incidents" where
>Netscape had weak implementations. He feels that companies will not trust software over the 'net. that
>they "want the US Government to say that 'this is good enough'."

I assume that the "two incidents" don't count breaking RC4-40.  I can't
remember two Netscape security incidents, unless he means to count RJC's
buffer overflow, all I can remember is Ian's key generation problem.

>Clint Brooks, of NSA, then went over the revised criteria. He claimed that they
>were surprised at the industry concern over "one product" for worldwide markets.

He stated that they were addressing "not domestic policy, per se, but we
keep wrapping around" because of the 'one product' issue.

The criteria are on the NIST page,
url: <http://csrc.ncsl.nist.gov/keyescrow/criteria.txt>

They handed out a guide to the changes in the criteria between September
and now. This is available from NIST as url:
<http://csrc.ncsl.nist.gov/keyescrow/bground.html>

Here is a portion of it:
Old Criterion 1.     Moved to #7;
Old Criterion 2.     Moved to #8;
Old Criterion 3.     Split into #1 and #2
Old Criterion 5.     Moved to #10
Old Criterion 6.     Moved to #9;
Old Criterion 7.     Moved to #5;
Old Criterion 8.     Moved to #6;
Old Criterion 9.     Deleted.
Old Criterion 10.    Moved to #3;

Only in Washington. Oh yeah, they also clarified a lot of the wording.

Ideas that I thought important enough to make notes of concerning the
criteria:

These criteria do not address either hardware nor non-escrow encryption.
Export controls of these are not changed, they can be exported with the
current procedures.

Brooks said that these rules are not applicable to the protection of
internal data for US corporations, even for overseas locations of US firms.
He said that getting permission to export for _internal corporate use_ is
easy, if it is to protect corporate secrets and for internal communication.
I took this to mean that a multi-national, US-based corporatgon can get a
permit for ViaCrypt and export it for their own use. [later in the day,
some people mentioned that this isn't nearly as easy as Brooks claimed.]

He said that the intent in the new wording is flexibility. They don't want
to prescribe implementation details, he wants industry to invent what
sells. He specifically stated that the meetings were not about setting
standards. This caused at least a fair amount of confusion, probably due to
the fact that NIST used to be called National Bureau of Standards, and NBS
set standards all the time. For example, a couple of folks were interested
in interoperability, say between a Netscape encryption system and one made
by, say, Microsoft. This meeting did not address this level of
interoperability.

about #2, "The product's key escrow cryptographic functions shall be
inoperable until the key(s) is escrowed in accordance with #3." Brooks said
that the intent was to allow vendors to make a single product that doesn't
activate the key-escrow function if not needed. The idea was that when the
keys are escrowed, the encryption engine would be activated. He also said
that "manufacturers may not want to be in the key escrow business" and
would therefore want to ship products that could be activated by a third
party escrow agent.

While talking about #3, "3. The product's key escrow cryptographic functions' key(s)
     shall be escrowed with escrow agent(s) certified by the U.S.
     Government, or certified by foreign governments with which
     the U.S. Government has formal agreements consistent with
     U.S. law enforcement and national security requirements."

He stated that this does not preclude the use of "other agents." This
became a major issue throughout the day. Ken Mendelson, staff attorney at
TIS, asked (roughly) "Under what authority does the US Government grant
certification to agents?" The response was a run around. Another hot issue
was whether you can "hold your own keys" rather than using a third party.
Seems that the corporate users are arguing that they want to hold their own
keys, and the government reacted to that favorably (not unfavorably?).
[Later in the day, Geoff Greiveldinger was asked if US citizens have the
right to hold their own keys. Geoff was forced to admit that, "yes, you can
hold your own keys"]

#5, "5.    The product's key escrow feature shall allow access to the
      key(s) needed to decrypt the product's ciphertext regardless
      of whether the product generated or received the ciphertext."

Contains a significant change that was not discussed in September. It means
that having the key for either end is sufficient. Brooks conceded that this
was a big change, but claimed it was needed. The claim that one-ended
surveillance is easier is most likely true.  It clearly is easier if one
end is US based and using GAK and the other is foreign where there is
respect for civil liberties.

He even claimed that it made the system less intrusive: His argument was
roughly:

Lets say they are snooping on me.  With one-ended, they can read all of my
messages, to and from, without needing the keys of my correspondents. (lets
pick Geoff G. as an arbitrary correspondent) With two ended, they'd have to
get both my key and Geoff's, and then they could read all of the messages
Geoff gets or sends.

I said it was _their_ argument. Seems to me to be groundless, unless they
got the keys of everyone in the chain, all of the folks that I talk to, all
of the folks that everyone I talk to, etc.

on "7.    The product's key escrow cryptographic functions shall use
      an unclassified encryption algorithm with a key length not
      to exceed sixty-four (64) bits."

This is really aimed at session keys, or at least non-RSA keys. I suggested
that they really needed some wording that make it clear.

>He said that the 64-bit key limit is not meant to restrict RSA keys to
>64-bits, but rather to restrict the session keys that are encrypted using
>RSA. Unspoken was the assumption that the 2000 bit RSA secret key would have to be escrowed.

on "8.    The product's key escrow cryptographic functions shall not
      provide the feature of multiple encryption (e.g., triple-
      DES)."

He pointed out that the wording used to say "prevent" and now just says
"not provide".  He acknowledged that "prevent" was impossible.

on "9.    The product's key escrow cryptographic functions shall
      interoperate only with key escrow cryptographic functions in
      products that meet these criteria, and shall not
      interoperate with the cryptographic functions of a product
      whose key escrow encryption function has been altered,
      bypassed, disabled, or otherwise rendered inoperative."

Brooks said that this was intended to allow multiple modes, such as
compatibility with other encryption schemes. Of course, he said, the other
modes are subject to export restrictions.

Somewhere in the discussion, Ed Appel took over for Brooks. Appel is
"Director of Counter Intelligence Programs, National Security Council, The
White House" He was introduced as FBI.

>There were some interesting (and bad IMHO) implications of interoperability.
I'll cover them more in the next section

Pat

Pat Farrell    Grad Student      http://www.isse.gmu.edu/students/pfarrell
Info. Systems & Software Engineering, George Mason University, Fairfax, VA
PGP key available on homepage               #include <standard.disclaimer>