ietf-mailsig
[Top] [All Lists]

Re: draft-delany-domainkeys-base-02.txt

2005-04-03 18:17:15

"Hallam-Baker," == Hallam-Baker, Phillip <pbaker(_at_)verisign(_dot_)com> 
writes:

    Hallam-Baker,> Going to per user keying means that we have a
    Hallam-Baker,> non-linear branch point that causes the DNS load to
    Hallam-Baker,> grow according to a completely different
    Hallam-Baker,> characteristic, moving from tracking server growth
    Hallam-Baker,> to tracking the number of users and the number of
    Hallam-Baker,> emails sent.
[. . . ]

    Hallam-Baker,> There are other problems that I think have to be
    Hallam-Baker,> considered, in particular the management aspect of
    Hallam-Baker,> the whole scheme. It is quite practical for a
    Hallam-Baker,> company like VeriSign to put in DKIIM records for
    Hallam-Baker,> our corporate mail gateways, the infrastructure
    Hallam-Baker,> that generates automatic mails, outsourced
    Hallam-Baker,> campaigns etc. and manage that infrastructure. We
    Hallam-Baker,> are talking about maybe 100 records total, all of
    Hallam-Baker,> which track business processes and can be
    Hallam-Baker,> integrated into the existing process.

    Hallam-Baker,> If we track users we need a lot more mechanism and
    Hallam-Baker,> infrastructure, we have to track something like
    Hallam-Baker,> 4,000 user accounts with a turnover of maybe 1500 a
    Hallam-Baker,> year. It is quite surprising how many very short
    Hallam-Baker,> term contractors and employees end up with mail
    Hallam-Baker,> accounts.

While you are right that you do need more mechanisms, speaking from
practical experience here at MIT, the management does not have to be a
problem.  Once deployed it can work quite well.  MIt generates about 5
RRs per user and our turnover is a lot higher than what you cite.  We
do not currently generate any per-user RRs corresponding to keys but
in principle there is nothing stopping us from doing so; it would be a
small matter of finding an application that would benefit and
programming the CA system to drop keys into DNS.

So I agree that you have identified a management issue.  I don't think
the issue is intractible and I think it provides an excellent
opportunity for improved infrastructure within organizations.  I think
creating a system that mandated such complex management would not be
acceptable.  however creating a system where organizations that can
handle the management complexity can benefit from better partitioning
and per-user keying seems fine to me.

I'm explicitly not speaking to cache load as I'm not qualified to do
so at this time.


<Prev in Thread] Current Thread [Next in Thread>