[14136] in cryptography@c2.net mail archive
Re: Is cryptography where security took the wrong branch?
daemon@ATHENA.MIT.EDU (Anne & Lynn Wheeler)
Wed Sep 10 11:09:30 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Wed, 10 Sep 2003 08:14:14 -0600
To: bmanning@karoshi.com
From: Anne & Lynn Wheeler <lynn@garlic.com>
Cc: lynn@garlic.com (Anne & Lynn Wheeler), cryptography@metzdowd.com
In-Reply-To: <200309101039.h8AAd9i25166@karoshi.com>
At 03:39 AM 9/10/2003 -0700, bmanning@karoshi.com wrote:
> There are some other problems w/ using the DNS.
> No revolkation process.
> DNS caching
> third-party trust (DNS admins != delegation holder)
Since DNS is a online positive list .... you change the database ... and
voila it is updated.
This is the scenario for credit cards going from pre-70s technology with
plastic cards and the monthly revokation booklet mailed out to all
merchants. The credit card industry transitioned to online infrastructure
where it transactions are denied by updating the online database. It
eliminates the revokation process, since there aren't an unknown number of
copies of static, stale credentials/certificates floating around the world
potentially being presented to an unknown variety of relying parties.
DNS caching is the closest equivalent of the certificate paradigm of
static, stale copies floating around the world. The two slight differences
are that cached stale, static entries tend to have very short lifetimes ...
they come into creation by activities by the relying-party (not the entity
being authenticated) and tend to have very short lifetimes .... of a few
hours to at most a day. However, relying-parties have the choice of going
directly to the root and obtaining the current copy .... a function
somewhat filled in the PKI world by OCSP .... although OCSP is just a check
about whether the current, static, stale copy in a relying-party's
possession is current ... not what the current entry is..
From information theory standpoint, stale, static certificates are
logically a form of long-lived, distributed, replicated, r/o, cache
entries. Cache entry semantics have been studied in some detail in areas
like distributed file systems and multiprocessor consistent shared memory
caches, etc. With short-lived r/o, distributed cache entires (like DNS)
... there is a trade-off involving 1) entry life-time, 2) frequency of
change, 3) impact of dealing with stale entry. We ran into a problem with
doing consistent database updates over NFS (network filesystem) because
while NFS advertises itself as item potent, most client implementations
have this 8k cache that can be stale.
Given high value &/or low trust ... relying parties still have option of
directly contacting root authority. And as outline, the root authority is
also the root authority for the CA/PKIs. If you attack the root trust
authority with false information .... then all subsequent trust operations
flowing from that false information is suspect. Domain name system still
has some exploits against the root database resulting in false information
.... but since that is the root for both DNS as well as CA/PKIs generating
SSL domain name certificates .... it is a common failure point for both
infrastructures. It needs to be fixed, in order to improve trust on either
the DNS side or the CA/PKI side (doesn't matter how thick you make the
vault door .... if somebody forgot to complete the back wall on the vault).
random, unrelated refs to past life working on processor cache design,
distributed filesystems, and distributed databases
http://www.garlic.com/~lynn/subtopic.html#smp
http://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
