Automatic key verification / CERT in DNS / RFC4398
brad at stop.mail-abuse.org
Thu Apr 6 20:21:52 CEST 2006
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
>> > 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/>.
More information about the Gnupg-devel