Subject: Re: Comments on rps-auth draft

From: Cengiz Alaettinoglu <[email-masked]>
Date: Mon, 13 Jul 1998 14:56:03 -0700

Jerry Scharf on Thu, 25 Jun 1998 15:51:15 -0700 said:
> having gone throught the permit for US export mill over the last year, I thin
k 
> the ISC experience with BIND can be useful.

definitely.

> 
> Thanks to the effort of John Gilmore, we now have a license from RSA to use a
n 
> authentication only version of rsaref in perpetuity. John has taken that 
> license and successfully exported a test version of BIND with this code 
> included and gotten no squacks. Unfortunately, the license we got with RSA 
> does not cover other signing applications beyond DNS. It does allow anyone 
> else to piggy back on this agreement for use in secure DNS for 3 years. This 
> sounds worse than it is, becasue the patents for RSA expire at/before then.
> 
> We have also negotiate an agreement with Cylink for thier DSS code, and this 
> is extendable to any IETF work, so you can sub that license via the ISC and 
> use their code to implement DSS into RPS.  Again, it is a authentication only
 
> library and we have clear signs from the State department that this code will
 
> not be challenged for export. A word of caution on DSS, unlike RSA it is very
 
> sensative to the quality of the random number generator, ie. if you have a ba
d 
> one "they" can crack the private key very easily. This appears to be by desig
n 
> not by accident.
> 
> With an ElGamal method, someone needs to go through and build a library that 
> can not be used for message encryption before it can be included. Since this 
> is not patent encombered, there are no license issues implicit in the 
> technique. You are allowed to include encryptionin the library, but it can no
t 
> be used for encrypting messages. You need some form of encryptor to manage th
e 
> private keys for signing, and this has already succeeded in passing State 
> department export in the RSA case above.
> 
> One other note that may be of less importance to you that to us. RSA is the 
> fastest algorithm to validate a signature. For BIND, this is very important.
> 

Yes, we only need to check signatures on updates and updates are very
infrequent.

> In any of these cases, separate releases and patches for foreign distribution
 
> should not be needed if you can follw the BIND path.
> 
> I am not well versed with the specific issues in france, russia, china and 
> other places with encryption controls. Since what you are trying to do in the
 
> similar ballpark to what has to be done for secure DNS/BIND, I would recommen
d 
> you go ahead assuming you can do what what BIND will do, and let BIND step on
 
> the landmines. Are there any things that are needed for this auth scheme that
 
> is not needed for BIND? If so, I'd like to understand that and warn you about
 
> the cost of breaking ground.

I dont think so. But I will let you know if something unexpected pops up
while implementing.

> 
> I'm not sure how else the ISC could be of help, but since we are on similar 
> paths it seems we should work together as much as possible.
> 

Thank you for the offer, and we (bird developers) really appreciate
it. Two questions, if we use the exact same libraries BIND uses, do we
still need to ask for an export restriction waiver? If so, how long does
the procedure take?

Thanks a lot.

Cengiz

> jerry

---

From: Jerry Scharf <[email-masked]>
Date: Tue, 14 Jul 1998 18:41:30 -0700

Cengiz,

maybe I'm just the paranoid type, but I think you have to check the
auth signature on every database fetch to prevent people from spoofing
the registry and sending you bad data. Since the idea of this is to
put some protection on the routing table (at least that's what i want)
I see every read as needing a public key chain check. So I do think you
have many of the same basic needs as secure DNS in this way.

I do think this will happen far less often than someone will want to
verify aol.com's mx, which is why you stand a better chance that DNS of
using DSS.

jerry

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 14 Jul 1998 23:49:21 -0400

> verify aol.com's mx, which is why you stand a better chance that DNS of

Hi Jerry,

The normal way of operating if you are configuring routers is to have
a local server.  When you do this you repeat the authentication and
authorization checks for every *change to the database* as it arrives.
This means checking some 100 transactions a day.

The alternate would be to check signatures on nearly 100,000 entries
(there are more entries in the IRR than there are routes in the
routing table) each time you build a set of router configurations.

The sometimes suggested alternate to signing transactions is signing
the objects themselves (which seems to be what you are thinking of).
The problem with signing the objects is that if you check the
authentication on an object, you need to make sure that it's entry in
the database was authorized.  To do that you must fetch other objects
from the database and authenticate them.  You must also determine that
those objects were authorized.  This means tracing back to the epoch
or at least to some trusted entity.  That could be a lot of work per
query.

It is much easier to simply query a registry (or mirror) that you
trust and rely on the signature of the registry on the query response.
If you are concerned about the integrety of the data and don't really
trust any of the registries, run your own mirror, and trust the
signatures on the queries from *your* mirror.

Since your mirror has been rechecking the authentication and
authorization of every change to the database since some epoch, if you
trust the administration of your own mirror, then you can be assured
that all of the changes to the database were authenticated and entered
according to the authorization rules.

I really think you need to look at the drafts before commenting.

Curtis