Automatic key verification / CERT in DNS / RFC4398

[Brad Knowles]

At 8:27 AM -0700 2006-04-06, Harakiri wrote:

>>  I doubt that signing a message puts more load on a
>>  server than all the
>>  spam filtering and virus scanning in use today.
>
>  This is actually true, signing a message (average
>  size) has not much impact of the server - maximum i've
>  seen is for PGP 200% the normal processing and 150%
>  more for openssl (yes, gnupg seems to be slower here
>  =/) - figures based on 50000 mails in a few minutes

	This is doing a PGP cryptographic signature on each and every 
message as it passes through the system, as compared to no 
cryptographic signatures at all?  I'd like to see more details of 
your testing, please.

>>  > 	Doing client-side signing and verification is
>>  definitely
>>  > scalable, but is difficult to get jump-started.
>
>  This is actually not right - because client side you
>  will always have the trouble to get all up to dates
>  CRLS, CAs, OCSP signer certs etc (im talking smime
>  here) and revoked keys for PGP. Do you want to update
>  every client every second to make sure the validation
>  is correct or just have *one* trusted server handle
>  the result which will take care of all CRLs, all CAs,
>  all OCSP Connections ?

	I think the problem of keeping updated CRLs, CAs, etc... is going 
to have to happen anyway, and I think that can be done in a scalable 
manner.  Teaching the clients to be able to use that system will take 
some time, but should not be excessively difficult.

>  I dont quiet get that point here, there is actually
>  enterprise gateways which use DNS lookups for
>  ceritifcate retrievale (x509) for over 4-5
>  years...nothing difficult when you only use 1 key
>  (domain/group key) for the domain

	Looking up a single DNS entry is not going to be particularly difficult.

	Doing a single signing key for the entire domain is probably not 
going to put an excessive load on the DNS server which provides that 
information, although it will greatly increase the amount of traffic 
that server handles -- instead of just handing out NS, MX and A 
records which aren't likely to fill an entire 512-byte UDP packet, 
now you have to add a whole bunch of crypto key data which is likely 
to greatly expand the amount of information you have to provide as a 
part of each transaction.

	The problem comes when you have a key per user.  Now you're 
talking about orders of magnitude more information that has to be 
handled, even with small numbers of users.  And exponential explosion 
in memory requirements, on both the authoritative and caching 
servers, which is guaranteed to cause a major meltdown when you start 
talking about tens of millions or hundreds of millions of users with 
keys published via the DNS.

>                                    - even then the DNS
>  entries can be expended for more users and there
>  should be no issue at all

	I think you need to look at the scalability factors before you 
make such proclamations.

-- 
Brad Knowles, <brad at stop.mail-abuse.org>

"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."

     -- Benjamin Franklin (1706-1790), reply of the Pennsylvania
     Assembly to the Governor, November 11, 1755

  LOPSA member since December 2005.  See <http://www.lopsa.org/>.