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(_dot_)mail-abuse(_dot_)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/>.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com