Automatic key verification / CERT in DNS / RFC4398

[Brad Knowles]

At 12:44 PM +0200 2006-04-06, Werner Koch wrote:

>>  	Keep in mind that relatively few people use any kind of personal
>>  encryption at all, and most that do make use of S/MIME instead of PGP
>>  or GPG, because S/MIME is what is provided by default from Microsoft
>
>  The problem with S/MIME is that you can't create a usabable
>  certificate for yourself.  You have to hand over a lot of money to
>  a more or less trustworthy CA with no real benefit.  OpenPGP may be used
>  much easier in that respect.

	S/MIME certainly has its share of problems.  But, it does have 
the weight of Microsoft and Netscape behind it.  All by itself, that 
sets a high bar to overcome.

>>  	So long as you stick to just one key for the entire domain, it
>>  doesn't matter if it's DKIM or PGP.  It still has some greatly
>>  increased CPU requirements (because every single message passing
>>  through the server will now have to be cryptographically signed,
>>  which will increase the CPU server load by many orders of magnitude
>>  per message), but at least it has the possibility of being scalable
>
>  I doubt that signing a message puts more load on a server than all the
>  spam filtering and virus scanning in use today.

	Most of what is done today is looking up information, both in 
local databases and remote ones.  For remote data lookup, you're 
basically stalled waiting for response from the remote machine. 
These process are mostly I/O intensive, and not so much CPU.

>  DKIM and other methods are also quite computing intensive.

	Yup.  All types of per-message cryptographic signing are going to 
be very CPU-intensive.  If that process is done at the client side, 
that's going to be scalable because each individual is not going to 
be sending that many messages, and they probably won't notice if 
sending a single message takes 1000ms versus the 10ms it used to take 
(or whatever the difference is).

	The problem comes when you try to do all that on the centralized 
servers because that's what is easiest.

>>  	We did try this technique before -- it was called pgpsendmail,
>>  and it cryptographically signed every message passing through the
>>  system.  It didn't work very well, and few people ended up using it.
>
>  Because the key distribution and validation of the keys was not solved.

	That was one problem, yes.  There were others as well.

>>  	Doing client-side signing and verification is definitely
>>  scalable, but is difficult to get jump-started.
>
>  Thus start with server-side signing using one key per domain.

	Which leads you to the scalability problem.

>>  	I don't think that's likely to happen any time soon.  The
>>  solutions which are easy to implement are non-scalable, and the
>>  scalable solutions are much more difficult to implement.
>
>  DNSSEC does not scale?  Okay, then DNS will eventually be useless.

	Are you doing per-query cryptographic message signing in DNSSEC? 
I don't think so.  IIRC, most expensive cryptographic operations are 
done when the zone(s) is/are loaded, and do not need to be performed 
again, which means that they can be cached.

	No such pre-processing/caching is going to be applicable for 
per-message cryptographic signing.

>  DNS-CERT does not scale?  The I* types will help to offload the keys.

	I'll have to read more about this before I can formulate an opinion.

>  PKA on a per user base does not scale?  Well, this might be a problem
>  with millions of users per domain.  I don't know for sure but I doubt
>  that, say, 64 extra bytes of user data makes any difference to these
>  providers.

	Speaking as the former DNS expert for AOL, I can tell you that it 
will definitely make a difference.  And I don't think it's going to 
be just 64 bytes per user.

-- 
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/>.