Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2006 15:10 -0400

On Mon, 21 Aug 2006 08:34:13 -0700 Dave Crocker <[email-masked]> wrote:
>Folks,
>
>Paul Hoffman wrote:
> > I see people who supposedly agree with each other about the policy
>> appear disagree on the required and requested response to the policy.
>> Some of that is because the tone of the messages is "this is obvious"
>> (which it is not), and some of it is because there are long-winded
>> discussions of the usefulness of the messages that don't concretely say
>> what the recipient should/must do.
>
>
>For the case of mail that is signed, I am still waiting to hear why it is 
not
>sufficient to have a third-party use a a sub-domain of the preferred 
(author, or
>whatever) domain name.
OTOH, it seems to me that it's been said Ad Nauseum.  Where feasible I 
agree it's better, but there are operational frictions that will impede 
this approach in some cases.

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

---

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Aug 2006 14:55:08 -0700

>this approach in some cases.
What I believe that we've discovered is that this isn't nearly simple as
some people hoped. Doing as little up front as possible so that you
can get operational experience is almost certainly better than guessing --
especially when the guessing wrong is a likely outcome. In this particular
case, I dooubt there will be harm because receivers will always have an
incentive to make better decisions (and hence the desire to upgrade).

       Mike

---

From: Damon <[email-masked]>
Date: Mon, 21 Aug 2006 18:43:35 -0400

> incentive to make better decisions (and hence the desire to upgrade).

With 15 years of design/build/operations under my belt for some Global
500 companies, being the 'wrench turner' or 'blue-collar guy' for what
comes out of these/our groups, I agree whole-heartily with what you
have said. I would like to add, in my opinion, put as many buttons,
bells and whistles on it as you can, I will find a use for them... or
not... at least I have a choice. Right now I feel like I am in a
Russian supermarket...

Regards,
Damon Sauer
Senders are Recievers too.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 22 Aug 2006 04:57:20 -0400

>> Scott Kitterman wrote:
>>
>> OTOH, it seems to me that it's been said Ad Nauseum.  Where
>> feasible I agree it's better, but there are operational frictions
>> that will impede this approach in some cases.

> Michael Thomas wrote:

> What I believe that we've discovered is that this isn't nearly
> simple as some people hoped. Doing as little up front as possible
> so that you can get operational experience is almost certainly
> better than guessing -- especially when the guessing wrong is
> a likely outcome. In this particular case, I dooubt there will be
> harm because receivers will always have an incentive to make
> better decisions (and hence the desire to upgrade).

By the same token, lets not exclude the possible (including the belated)
recognition of some problems and the receiver decision to either a) punt on
DKIM, or b) use the new failure discoveries as a way to further filter bad
mail much to the chagrins of those who want all DKIM mail to reach some
trusted-layer or the final user.

In my view, the only guessing here is who some are believing that DKIM-BASE
will be accepted as is and that receivers will past the buck to trusted
layers.  That would be a highly risky erroneous presumption to make for a
wide adoption strategy.  It may work in the vertical market but not in the
horizontal market, in fact, there is a high probability that the horizontal
market may suffer some consequences when the high-value smaller vertical
market begin to get exploited, by name only, and the attacks are focused
much larger segment of the market.

But I agree, receivers will be quick to recognize the problems promoted by
the uncontrolled usage of DKIM-BASE protocol and will adapt accordingly.

Having said that, the only thing I seek, I don't care how you want to do it,
is to offer controls of who is allowed to sign mail on the behalf of the
2822.From: domain and I don't want a "batteries required" concept of asking
some independent organization for this basic protocol consistency
information.

That will happen anyway but only after all the i's are dotted and t's are
crossed.  No one has disputed reputation or accreditation ideas. They are
also part of total picture solution.  But for DKIM-BASE, we have some
fundamental protocol inconsistencies issues that can be easily resolved with
signature authorization policy ideas such as SSP.

Finally, I think most of it is already covered, as witness with the SendMail
Milter public open source code (dkim-milter-0.5.1) which currently supports:

    Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
    Signature Expected  (o=- DKIM_POLICY_REQUIRED)
    Signature Not Expected (o=. DKIM_POLICY_NEVER)

However, the 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as
defined in SSP-01 and a header bit declared, is not supported in the milter.
There is no action for it.  See the case statement in DKIM.C:

  ret = DKIM_STAT_OK;
  policy = dkim_policy(dkim, &test);

  switch (policy)
  {
   case DKIM_POLICY_SIGNSOME:
       break;

   case DKIM_POLICY_REQUIRED:
       if (!msgsigned)
        ret = DKIM_STAT_NOSIG;
       break;

   case DKIM_POLICY_AUTHORITY:
       /* XXX -- verify signer domain and sender domain match */
       break;

   case DKIM_POLICY_NEVER:
       if (msgsigned)
          ret = DKIM_STAT_BADSIG;
       break;

   case DKIM_POLICY_USER:
       ret = DKIM_STAT_NOTIMPLEMENT;
       break;

   default:
       ret = DKIM_STAT_SYNTAX;
       break;
  }
  if (msgsigned && !verified)
      ret = DKIM_STAT_BADSIG;
  return ret;

As you can see, the DKIM_POLICY_AUTHORITY policy is ignored.

So Mike, offering support for DKIM_POLICY_AUTHORITY is really at the very
least I am personally advocating for because without out, I believe it
lowers the technical and marketing value of DKIM-BASE and the protection it
may offer to domains who may want it.

If we can stop trying to find out WHY one will want this, and just accept
that some MIGHT want it (which I strongly believe many will), and program it
into the protocol and verifiers, such as the SENDMAIL MILTER, then it will
finally give me some reason to begin implementing this stuff.

Without, anyone can sign without restrictions and that doesn't help the
domain or the receivers one bit.  We are back to the same vague NEUTRAL open
ended issues that were problematic with SPF.

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