Subject: RE: [ietf-dkim] Re: Delegating responsibility: a make vs. buydesigndecision

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 24 Aug 2006 11:06:33 -0700

This discussion seems to be going round in circles.

Lets go back to some basic principles that we try to make general laws:

1) Each party that claims responsibility for a message does so in their own name

2) If a party wishes to delegate signing capability (in effect a PP signature) then this structure should be visible in the policy architecture

3) The only DKIM policy record useful to a recipient states 'everything I send has a DKIM header'

These principles seem to me to suggest the following approach:

1) The domain owner adds a dummy DKIM header
2) The actual sender accepts responsibility in their own name.

OK so what might a dummy header look like?

* The signature is not 100% effective
* It has a selector

If the email sender is sending out identical content to every recipient then it would make sense for the domain name owner to sign the content but not the sender field to create the dummy header.

If the messages are going to be customized for each recipient then the dummy header would not cover either the content or the sender. If this practice is to be widespread we should define a NULL algorithm to save the recipient the need to check a useless signature.

The selector can contain statements that are in effect policy language. For example:

* This key record can only be used with the outbound email address [email-masked]
* If this key record is used there MUST also be a signature from party Y.

I think that the above meets the use cases described. Each key record is in effect a policy statement insofar as publishing a key record means that you are defining a set of acceptable criteria for authentication.

The SSP record contains only the statement that everything has a DKIM header. 

As I see it there are only two useful routes to extending the policy record beyond that.

* The SSP record states that every message sent has 1...n DKIM headers where the key selectors meet stated criteria.

* If no header is present then a key record can be obtained by applying a given set of rules. (this is a powerful idea but the complexity does not seem to be justified by the return).

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

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 24 Aug 2006 14:36:35 -0400

> Phillip wrote:
>
> * If no header is present then a key record can be obtained by
> applying a given set of rules. (this is a powerful idea but the
> complexity does not seem to be justified by the return).

Phillip,

This is all great, but no one is answering the fundamental question that
will stop bad actors from "indirectly" spoofing your domain.

By "Indirect",  I mean the bad actors who do not support DKIM,  probably
doesn't even have a clue about it or does but he sees the verifiers don't
check for policies so No Signature is the greatest loophole possible - a "do
nothing" concept on the part of the spammer!!   Its a wonderful discovery -
"I found the secret to defeat DKIM - Do nothing!"

If we don't address this, then the bad actors have 100% incentive to not
even try to circumvent DKIM.  They  don't need too.  Just don't sign mail or
even try to fake it.  Totally ignore DKIM.   We don';t even have incentive
for the "Good Spammers" to support DKIM.  They don't have too.

Solving this one, as you said, is a very poweful idea, and the solution,
IMO, is the basis for all other possible scenarios.

Complex?

I don't think so.  No, not really.  Not from my standpoint.

At the very least, it should be the 2822.From: since because in the end,
protecting the 2822.From Display field approaches the ideal maximum
protection that will be shown to the user and for that which we have been
seeking here.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com