Keyservers and the future

[Radu Hociung]

Sean C. wrote:
[snip]
> This would not be the end-all be-all of anti-spam tools. It would just be a
> method to authenticate mail as really originating from a particular domain. You
> would still use other tools (eg SpamAssassin, Norton, etc.) to figure out if the
> sender is a known spammer/open relay or if the content is (like) spam.
> 
> 
>>>DomainKeys, for instance, works at the transport level. Somewhat like
>>>SSH, where the client and server use one key to encrypt the datastream,
>>>but a different key is used by the user to actually authenticate and log
>>>in. DomainKeys does not encrypt the channel, but it only signs it (it
>>>signs a subset of the message headers as well as the body of the
>>>message). If a recipient domain trusts Yahoo's keys, he can assert that
>>>the mail really came from the Yahoo domain. This is a per-domain
>>>signature, not per-user.
>>
>>Where does the secret key reside?
> 
> 
> The sending SMTP server?
> 
> 
>>Who controls the signing?
> 
> 
> The sending SMTP server?

Thanks Sean for your explanations. They are in exact agreement with what
email authentication wants to be.

I would like to add another note on the the number of total keys that
may be required. This will also answer Neil's other question:


Neil Williams wrote:
> I've got many domains but I only want one main key.
> 
> If someone trusts codehelp.co.uk does that mean they also trust dcglug.org.uk 
> just because I've got both in the UID's of my key?

The fewest number of keys is needed if the scheme allows each domain
owner to use 1 key. A domain owner is the person who has one or more
domains. At a minimum, there would be as many keys as there are people
who own internet real-estate (domain names). If you own 100 domains, you
can of course use 1 key.

As for the maximum number of keys needed:

Private key distribution remains a problem. DomainKeys has a solution to
this problem:

With DomainKeys as used by yahoo.com, each mail server machine has its
own private key. This avoids the need to copy a master key to all mail
servers, which are deployed world wide possibly. So there are a
multitude of keys that each domain signs with.

There is an additional practical issue of hardware failures. When a
hard-disk fails, the machine is sent to the technical support
department, who replace the failed disk with a new one. However, if the
private key is stored on the hard disk, it must now be revoked, as the
technicians have access to extract it. This problem can be solved in one
of thee ways:

1. Store the key on the hard-disk, but revoke old keys when hard-disks
are replaced (due to failure or pre-emptive maintenance).

2. Do not store the key on the hard-disk, but generate it in memory
every time the machine is rebooted.

3. Use a security storage device in each machine. Keys need to be
revoked when machines are retired.

Any one of these models will see many keys in use for each domain. After
a few years, the majority of keys will be revoked and expired keys.

There is also another issue of Public Relations:

Some domain owners own many domains and run their own servers, as Neil
pointed out. In this case, one key is sufficient for many domains.

However, many domain owners get their ISP to run the mail servers, in
exchange for a monthly due. When an ISP handles several domains, the
respective domain owners would not want their domain's mail to be signed
with the same key as another domain that the ISP may be hosting. So each
 of the ISP's mail server machines may at any one time host hundreds of
domains, and need to maintain a separate private key for each of those
domains.


If you combine the security issues outlined for DomainKey with the PR
issues of ISPs hosting multiple domains, the maximum number of keys
required globally to implement email authentication may be much larger
than the number of domain names actually registered.

I think at a minimum we're talking tens of millions of keys, and at
maximum we're talking tens of billions of keys.

I understand that due to the security issues, a revoked key cannot be
deleted before its expiration date. This would imply that at any one
time, the cost of email authentication will be about double the number
of active keys at any one time. The key deletion feature does not exist
in the current keyserver, as far as I can tell.

Regards,
Radu.