Subject: Re: DNSSEC (RE: Software for PKI)

From: [email-masked]
Date: Fri, 9 Nov 2001 16:55:31 -0700

i managed to fat finger some number of the URLs in the previous note ...
they've been corrected in the version at:
http://www.garlic.com/~lynn/aadsm8.htm#softpki19

---

From: [email-masked]
Date: Fri, 9 Nov 2001 10:16:41 -0700

but the cache protocol has life-time specified nominal is in the range of
minutes to hours  ... which is much better than years for certificates. you
don't actually have to revoke a key ...  there is just the maintenance of
what is the valid key (if any) ... and the issue of what size caching
window that you are willing to tolerate for the data. A hypothetical key
compromise could take on the order of hours from occurance, discovery,
administrative to validate report, etc  .... so a reasonable policy might
still be a cache life-time of  an hour.

and if you were really paranoid you can also do a DNS transaction that
looks up the data directly from the server, bypassing the caching i.e.
client could choose to bypass whatever the infrastructure chosen policy for
cache life-time .... supporting both institutional-centric policy and
client-centric policy.

[email-masked] on 11/9/2001 9:57 AM wrote:

Lynn,

yes and no. One of the problems is that you cannot actively "revoke"
a key or a signature other than physically delete that information
from the DNS zone file. However, the DNS data will still be
cached in dozens of servers out there.

Cheers,

           Stefan.

-------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant

Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe

Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail [email-masked], http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B

---

From: [email-masked]
Date: Fri, 9 Nov 2001 14:44:17 -0700

yes, well, humm.

my wife and I had been doing these networky things
http://www.garlic.com/~lynn/internet.htm#0
http://www.garlic.com/~lynn/subtopic.html#hsdt
http://www.garlic.com/~lynn/subtopic.html#osi

as part of some generalized high-assurance data processing
http://www.garlic.com/~lynn/subtopic.html#lcmp
http://www.garlic.com/~lynn/subtopic.html#smp

anyway several years ago, we were doing some consulting to this financial
services company and somebody from this new, small client/server startup
wanted to do financial transactions and my wife and I got assigned to work
with the small startup (in part because we had worked with the people in
charge of the project in previous life):
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/2001i.html#52

in any case they had this thing that they were going to call SSL for
protecting the transaction/information in flight .... that involved these
things called certificates. As part of the assurance review ... there had
to be a detailed end-to-end business process audit ... that was
significantly more than end-to-end protocol assusrance audit.

Out of the end-to-end business process reviews and deploying the stuff in
operational environment (now frequently referred to as electronic commerce)
we happened to gain some working knowledge about where the security and
trust issues were. It has actually seen fairly wide-spread and succesful
deployment.

Some of this experience went into the financial industry work on a
electronic payment standard for all account-based transactions
http://www.garlic.com/~lynn/index.html#x959

and some of it went into attempting to apply public key authentication
technology to existing business and technology infrastructures:
http://www.garlic.com/~lynn/subtopic.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius
http://www.garlic.com/~lynn/index.html#aads

note that it is possible to apply public-key distribution as part of the
existing DNS infrastructure as in this discussion thread. Another
application of public-key authentication technology is to integrating it
into existing RADIUS (and/or other) client authentication infrastructure
.... effectively substituting the registration of a public key in place of
registration of a password. In the DNS case, it is to leverage a widely
deployed information distribution protocol to also distribute public keys.
In the RADIUS (and similar cases) it is for the relying-party to directly
use their own public-key registration database w/o actually distributing
the keys. There is something of a gray area with regard to the sematics of
the process ..... in one case it can be viewed as information push from the
database (sort of as in the DNS cache scenerio) and in the other there is a
information pull from the database (as in the case of real-time access by
RADIUS to the enterprise authentication database).

In any case, the DNS use of caching is a pure implementation thing. Lots of
the above .... all the requests always execute against the actual real-time
data .... as opposed to having a temporary cache.
Now, in database terms, from work that we did on distributed lock manager
for super-scaling database
http://www.garrlic.com/~lynn/subtopic.html#hacmp
as well as some experience working on design of CPU caches
http://www.garlic.com/~lynn/subtopic.html#smp

things can be stated in terms of strong memory consistency, to week memory
consistency, to fuzzy memory consistency. The degree of distributed memory
consistency tends to be somewhat dependent on the application requirements.
Financial transactions tend to have relatively strong memory consistency.
And for some cases, you avoid doing distributed memory at all and all
requests execute directly on the repository. Most public-key distribution
consistency issues are somewhat simplified because there aren't actually
real distributed transactions (changing public key values). All the
existing caching schemes have tended to be R/O caching (certificates can be
viewed as one form R/O distributed caching of information). The upside of
certificates is that they are useful for offline environments. The downside
of the existing certificate distribution schemas have effectively little
bound on the number of places that R/O copies might occur. DNS is
significantly better than that ... with the bounding not so much better in
space ... but significantly better bounded in time. It is reasonable to to
do a risk assurance on the DNS time-bounding and possibly dynamically
adjust values. Also, there is a much more robust distribution
infrastructure (from the services stand-point). By comparison, certificates
have tended to go to the entity registering the public key and then they do
arbritrary re-distribution. By comparision a distributed transaction
database that confirms to strick ACID properties will always be able to
predictably do transaction operations.

Similar to the RADIUS case is the application of registering public-keys at
financial institutions using effectively the same business process used to
register PINs (frequently seen in debit &/or atm related activities):
http://www.garlic.com/~lynn/nacharfi.htm
http://internetcouncil.nacha.org/Projects/ISAP_Results/isap_results.htm

All of these can be done with a combination of RA technology (from the CA
world for registering public keys) and existing business processes
currently used for managing other types of authentication information (aka
technology upgrades while maintaining existing business processes .... as
opposed to trying to introduce radical surgery on business operations).

there has also been a lot of effort put into the hardware token effort:
http://www.garlic.com/[email-masked]#straw
http://www.garlic.com/~lynn/index.html#aads

a lot of it tho has come out of prior experience in deploying complex,
industrial strength, dataprocessing environments.

[email-masked] at 11/09/2001 12:19 pm wrote:

Lynn,
This is interesting.  What you are saying is that server-based PKI (sort
of)
that generates fresh (or short-time cached) responses from a database
is the way to go.

This is essentially the same thing I have been pushing several years for
extranet authentication.  That each company server generates freshly
signed "tickets" (http://www.x-obi.com/purple) based on their databases
instead of issuing and distributing employee certificates.

Server-cryptography rulez!

These DNSSEC servers will not be practical until HW-crypto
support is down in the $100 region.   This may take another
5 years or so.  It is driven by the B2B market that needs such
servers as well.

Anders

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 12 Nov 2001 09:19:27 +1300 (NZDT)

[email-masked] writes:
>These DNSSEC servers will not be practical until HW-crypto support is down in
>the $100 region.   This may take another 5 years or so.  It is driven by the
>B2B market that needs such servers as well.

It'll never get into the $100 region.  The same rule that says that a single
frame of CGI takes 20 minutes to render no matter what year it is (as hardware
and algorithms get better, more complexity is added to the scene which negates
the speedups) also says that crypto hardware will never sell for less than
about $500.

OTOH if you mean the crypto hardware which is labelled "AMD Athlon" then it's
already in this price range, and performs better than many $500 cards.

Peter (who has a Racal Datacryptor somewhere in his collection... if anyone's
       ever tossing out old crypto hardware, feel free to dispose of it in my
       direction so I can add it to my museum).

---

From: [email-masked]
Date: Fri, 9 Nov 2001 15:13:43 -0700

oops, the client for current SSL is getting several transmissions from a
single source .... and only because PKI has not been implemented (just
certificate manufactoring .... if PKI implementation was ever attempted,
the client could have a huge number of responses with large number of
different entities).

Yes, SSL needs the option of working in the non-DNS environment.

However, the discussion started with my clain with regard specifically to
SSL domain name certificates possibly accounts for 99.99999 percent of all
certificate relateed operations that occur in the world today and the
supposed purpose for the existance of those SSL domain name certificates
was because of perceived integrity problems with the DNS domain name
infrastructure operation. Also that within the context of that purpose for
the existance of the SSL domain name certificates and representing a
significant percentage of all such operations .... that something else
might make sense.

It might be useful for having a specific optimization for 99.99999 percent
of the events .... and let the remaining .0000001 percent of the events be
done the less efficient way.

Aka, in a DNS environment ... the client has to make the DNS call
regardless and get the DNS results regardless. Piggy-backing the public key
on that call does not increase any additional client transactions with any
addition entities.

Then SSL setup is done in a single round-trip .... for possibly 99.999999
percent of the cases.

And SSL could be done some other, less efficient  way for the remaining
.0000001 percent of the cases.

The difficulty of having such an option isn't any worse than the existing
option for mutual certificate authentication which gets used even a lower
percentage of the time than the non-DNS operations.

[email-masked] on 11/9/2001 12:50 pm wrote:

In fact, what was proposed at the time was an optimization whereby if
the client knew the server's public key and preferences (never mind
how) it could short-circuit the handshake. This would also have
allowed the client to cache the server's identity data.

In any case, this doesn't really simplify things very much. The client
needs to process much the same data but from two sources rather than
one. And since SSL has to work in situations where DNS is not
available, you need to retain the full handshake anyway so you've
added complexity to the protocol, not subtracted it. At the time the
sense of the group was that DNSSEC was insufficiently deployed to make
this a worthwhile optimization. Things haven't changed much in 5
years.

-Ekr

--
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: [email-masked]
Date: Sun, 11 Nov 2001 11:58:35 -0700

and from the archives on a long ago, far away project  ... price has come
down some ....

Date: 1 July 1985, 08:17:15 MDT
To:   WHEELER

Lynn,
re: your questions about the public key encryption unit
  The Racal-Milgo Datacryptor III uses a AMD DES chip plus some proprietary
logic for exchanging master keys using a public key approach.  The master
keys
are then used to encrypt the working keys which are actually used for data
encryption.  I have run the off the shelf units at 128kb full duplex
through
the V.35 interfaces contained in the unit.  They cost about $3,200 each,
single unit price.
  I have to emphasize they are link level encryptors (e.g. level 1) rather
than level 2 (e.g. only the data encrypted with addressing in the clear).
They won't do you much good for "session" or "file" encryption.
  The public key synopsis goes something like this -
1. At install time, two 60 digit prime numbers are acquired and retained in
   storage.  The 'seeds' are developed by a combination of an operator
   pressing a button to sample a clock source along with internal logic.
2. When a operator wants to move a master key online, he asks the remote
end
   for a one-time E key (56 bits plus 8 parity bits).
3. The remote end uses the two 60 digit prime numbers (with their 120 digit
   product) to create a E key and a D key.  They are "mathematically
related
   to the prime numbers and to each other" to quote the Racal
documentation.
4. The E key can't be used for decryption and the D key can only decrypt
   what has been encrypted with the E key.
5. The remote end retains the D key and sends the E key to the 'requestor'.
6. The local end generates a new master key, encrypts it with the E key he
   just received, and sends it to the remote end.
7. The remote end decrypts the transfer with the D key he retained, they
   exchange a test message for verification, and exchange a new working
key.
8. The E/D pair of keys are not reused.  Each exchange of a master key
causes
   a new pair to be created.  The E/D pair never leave the boxes, and can't
   be read out or displayed.  It takes about 8 seconds for the hardware to
   do the decryption of the received master key using the D key previously
   retained.

[email-masked] on 11/9/2001 12:19 pm wrote