[2960] in cryptography@c2.net mail archive
Re: IETF building GAK into the PKI
daemon@ATHENA.MIT.EDU (Adam Back)
Tue Jul 14 16:51:41 1998
Date: Tue, 14 Jul 1998 20:55:45 +0100
From: Adam Back <aba@dcs.ex.ac.uk>
To: perry@piermont.com
CC: cox@djehuti.com, cryptography@c2.net, pgut001@cs.auckland.ac.nz
In-reply-to: <199807141756.NAA03524@jekyll.piermont.com> (perry@piermont.com)
Perry writes:
> We must be careful to keep in mind that almost all the proposed forms
> of GAK out there have *no* business application. No business wants to
> be able to tap its employees NFS traffic and such. GAK in network
> protocols is utterly useless to business.
> [...]
> They [businesses] want key recovery for DATA. Not for interactive
> communication.
Agree 100%.
> PKIX is a public key infrastructure. Public keys are used for
> interactive communication -- very rarely, if ever, are they used for
> things like data storage. The result of this is that GAK is worthless
> to any business in its public key infrastructure. Only the government
> wants it. There is no legitimate business function here.
Absolutely.
Now the purported problem that people who propose GAK enabling
solutions throw up is that for the special case of email, that email
is both storage and communication.
I consider this innacurate: email in transit is communication, and
email in mail archives is storage. The 11 cryptographers report fails
to make this distinction, which I think it would have been useful to
make.
With the PGP CMR (Corporate Message Recovery) proposal Peter mentions,
much effort was spent discussing on the ietf-openpgp list and
otherplaces trying get across the points that:
a) message recovery is dangerous because it partly enabled GAK,
and b) for email systems, with small amount of effort one can remove
this risk, and increase security at the same time without losing
the functionality required by business
With ietf-openpgp (draft-ietf-openpgp-formats-05.txt) the result of
protracted discussions was that what used to be "an ARR tag"
(Additional Recipient Request -- the potential GAK mechanism) is now a
"placeholder for backward compatibility". This was a good result!
I would be most pleased to see the same happen to the corresponding
GAK risk mechanisms in PKIX, and welcome all cooperation and feedback
on how best to influence the outcome in this direction.
One argument against putting GAK enabling things into IETF standards
is that there is an RFC specifically suggesting that it not be done,
and the additional general IETF stance that political considerations
not be allowed to weaken standards. GAK is a pretty good match for a
political consideration, and the result clearly weakens security.
The remaining arguments about escrow being useful for public keys can
be dismissed as wrong headed, and a security risk for the reasons
Perry states.
The lesson as applied to email encryption is that using the same keys
for long term storage as for communication encryption is a _dumb
move_!
Communication encryption keys should be rekeyed periodically ideally,
and using them as the basis of securing an email archive prevents
destroying old keys.
Email archives should be stored either in plaintext (a reasonable risk
assessment if all the documents being exchanged are themselves in
plaintext on the disk), or the mail archive or whole disk should be
encrypted, one presumes with symmetric encryption, and with the normal
backup mechanisms which one might use to ensure availability of data
on disks: namely regular backups, and key escrow of storage keys
within companies to protect availability of their data.
The reason that the approach of using different keys for storage
improves security is that encryption keys can be expired, and wiped
providing forward secrecy, without losing access to the mail archive.
Even a new key per year is better than recommended expiry period
"forever" (a certain email security program).
That there are advantages to using separate keys for very different
purposes (storage, confidentiality of messages in transit) should come
as no surprise, and is analogous to the case for separate signature
and encryption keys.
That such resistance is put up to the notion of doing things properly
and distinguishing between storage and communications keys from poeple
who otherwise claim to be resistant to the idea of GAK is hard to
follow.
The additional effort is worth it from a security perspective already,
and surely worth the extra effort in reducing risks of GAK.
As Peter commented, GCHQ in the UK (UK NSA equivalent) have already
proposed their own profile of PKIX and S/MIME making use of the
proposed PKIX "key archive" feature, providing a real life present
tense demonstration of why we SHOULD NOT INCLUDE GAK in IETF
standards.
(And a copy of GCHQ GAK proposal CASM, is available on the web here
for anyone wanting to see for themselves the dangers:
http://www.opengroup.org/public/tech/security/pki/cki/
)
Adam
--
print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
