DKIM Deployment

[Dave CROCKER <>]

Bob,

Yum.  What a tasty message.  Thanks for sharing.  Lots to chew on...


RL 'Bob' Morgan wrote:
> Assume a situation where your campus has a primary set of MTAs that most 
> outgoing mail goes through for all kinds of purposes:  
>   ... so not everything goes through the central
> ones, but most does. The simple assumption is that if your site decides 
> to do DKIM it would sign all messages sent from these MTAs.

I think this describes an environment where some of the mail is out of the scope 
of control of the organization and hence the organization should not be seen as 
taking responsibility for those message.

Most organizations don't even know all of the MTAs sprinkled around sending mail 
under the organization's domain name (in the From: field).  They couldn't sign 
everything even if they wanted to.

Especially during early stages of adoption, this probably describes all 
organizations, except very small and completely disciplined ones.

At the least, it suggests trying to distinguish among different mail streams to 
identify potentially different responsibilities.  Something from a Chancellor's 
office probably permits taking more responsibility than from the dorms.  Sign 
them with different d= DKIM parameter domain names and the receivers can develop 
different reputations for the different mail streams.

It's probably worth clarifying a basic point about DKIM:

     DKIM does not certify that the contents of a message are valid, that the 
author From: field is valid, or frankly that anything is true or safe about a 
message except the signature.  Or, rather, the identifier that is used in the 
DKIM-Signature: header field.  So, DKIM is nothing like OpenPGP or S/MIME. 
Given that DKIM is touted as an authentication mechanism, that sounds pretty 
bizarre.

     DKIM is merely a way of associating a "responsible" organizational 
identity to a message, where the exact meaning of "responsible" is not really 
defined in the DKIM specification, except that the responsibility is limited to 
transmission rather than necessarily having anything to do with content.

The responsibility is intended as a short-term assertion for use in email 
transmission decision.  And the responsibility is at an organizational level, 
rather than a personal one.  (OpenPGP and S/MIME are personal and long-term.)

So, the most basic meaning is that DKIM gives you an organization to point to 
and contact, if there is a problem with the message.  Someone to blame and deal 
with.  That you can believe really is responsible, rather than an identity that 
has been spoofed.

Any responsibility beyond this needs to be developed over time, through 
reputation assessment mechanisms.

Therefore I think it can help discussion to re-cast your query as being "what 
messages should the organization take responsibility for?"  And I think that's 
really the view that your message landed on, toward the end of your message.

Especially during these early days of DKIM use and most especially during the 
early stages of DKIM adoption, I suspect most folks will decide that the answer 
would be to take responsibility for as little a necessary to get the "important" 
mail delivered.

Start small and grow carefully.


> At the meeting I think some people were nervous about that, since we 
> know that there may be many sources of spam/phishing from our campuses, 
> via stolen accounts, hacked machines, even enterprising students or 
> staff.  If we sign everything we'd be tarnishing our reputations and 
> obliging ourselves to take responsibility in some fashion for all that 
> bad traffic.
> So we would restrict signing to some more well-behaved mail streams.

Exactly.


> I think DKIM orthodoxy, on the other hand, says that indeed everything 
> should be signed.  

DKIM has been a standard only for 1 1/2 years.  Prior to that, adoption was only 
among a very small set of organizations.

I think you are correct about what is the common view, but really the orthodoxy 
is based on theory rather than practice.  As practice is developing, or at least 
as people try to develop deployment plans, they are encountering exactly the 
challenge you are citing.


>  I think the argument goes that if you are injecting
> messages into the Internet mail system then you are "responsible" for 
> them whether you sign them or not.  

Certainly receivers would love to be able to base their decisions on something 
that simple.  But they can't.  Anymore than they can treat the promises of an 
organization's janitor the same as of a CEO.

So the best that can reasonably be demanded of is that mail that is signed 
distinguish between major categories of mail.

It can help to think in terms of setting expectations in a way that the signer 
has some chance of meeting.  Trying to sign everything allows undisciplined mail 
to pollute the reputation of mail streams from the more disciplined parts of the 
organization.  It sets the expectations very high -- I would say too high -- 
from the start.


>     Signing just helps recipients 
> determine more easily and accurately that it really was your MTAs that 
> forwarded them.  If you let lots of bad mail go through and take no 
> actions to stop it then your reputation will suffer in any case.  
> Signing doesn't make you more liable or accountable really, it just 
> makes clear who the accountable party is.

Exactly.

d/
--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net