Subject: RE: [ietf-dkim] user level ssp

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 6 Sep 2006 21:23:42 -0700

> [mailto:[email-masked]] On Behalf Of John Levine

> >Could someone please explain the nature of the problem that 
> would exist 
> >when these (financial) institutions can't selectively add DKIM 
> >signatures to outbound email? Engineering is about balance, but I 
> >haven't heard enough to make the trade off yet.
> 
> I think the alleged problem that putatively needs to be 
> solved is that bigbank.com somehow manages to get signing in 
> place for their employees whose names start with A through M, 
> but hasn't get gotten around to doing so for N through Z and 
> wants to tell the world that it signs all ofthe A through M.
> 
> I have to admit that I don't see this as a problem worth 
> solving, either.

As I pointed out earlier, it is possible to define the policy scheme in such a way that per user policy is a backwards compatible upgrade that can be added in later if it is found to be useful.

Achieving such a situation is a good way to strip out questionable features. There are certainly use cases but whether those use cases are compelling is another issue. Per user keys are not the same thing as per user policy.

I think it is entirely likely that bigbank.com would have a situation where the mail servers for its east coast offices were adding signatures but the ones for the west coast were not. The part that is less easy to see is whether there is value to the short term fix. It is probably easier to just do the deployment. But it is not certain that this will be the case.

Conclusion: hedge our bets, make sure we can deploy per user policy should we need to. Reversing the priority so that the domain policy record is always the master seems to me to be the right approach here. 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: [email-masked] (Wietse Venema)
Date: Thu, 7 Sep 2006 07:23:11 -0400 (EDT)

Hallam-Baker, Phillip:
> I think it is entirely likely that bigbank.com would have a
> situation where the mail servers for its east coast offices were
> adding signatures but the ones for the west coast were not. The
> part that is less easy to see is whether there is value to the
> short term fix. It is probably easier to just do the deployment.
> But it is not certain that this will be the case.

This hypothetical bank can use the hypothetical "I sign some of my
mail" policy until the DKIM roll-out is complete, and then transition
to the "I sign all my mail" policy.  

A per-user mechanism is not the obvious solution for this problem.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Thu, 07 Sep 2006 07:35:35 -0700

> A per-user mechanism is not the obvious solution for this problem.

Agreed.

Problem: When to trust just the domain?

Case 1:

Bigbank.com wants their email-messages annotated with high assurances on
the basis it verified as coming from their domain, but a general high
assurance is not appropriate for all of their messages.

Case 2:

BigISP.com signs millions of messages per day, but only specific
email-addresses are protected internally and are from trustworthy
sources. BigISP.com wants only messages that have these protected
email-addresses annotated with high assurances.

Solution:

An email-address specific policy is a natural way to convey which
email-address should be annotated as being trustworthy based solely upon
the domain from which it verified.

DKIM's primary role at protecting transactional messages from being
spoofed is greatly enhanced with a per email-address policy.  Private
exchanges can utilize other clues, such an email-address found in the
address book when making different levels of assurance annotations.

Domain assured email-addresses may not be found in an address book such
as do-not-reply@, where each organization has a practice of using
different email-addresses to play these critical roles.

-Doug