ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] requirements

2006-07-27 18:18:34

----- Original Message -----
From: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
To: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>

Regardless of the OA, spam will reflect poorly upon the signing
domain.  Reports of abuse and expectations of who will resolve an
abuse issue  always falls to the signing domain.  There will not be
any "spreading" of responsibility.  There is no means to know whether
the OA is even valid!  The identity of the OA depends upon the
assertion made by the signing domain.

"Spreading" was perhaps not the right word to use.  But the signature is
now coming from a different place, so whom it reflects poorly upon is
now changing.  That makes it a fundamentally different thing than key
delegation.  Allowing a domain to delegate the ability to sign their
mail and not holding the delegating domain responsible at all seems
undesirable in that it doesn't discourage domains from doing business
with dubious mailing services.

Is it possible to view this from a VERIFIER security standpoint based on
what is to expected in DKIM-BASE and all possible signatures regardless what
is deemed useful or not?

After, the verifier is going to be the ultimate "controller" of what gets
processed, what get disseminated, filtered, etc.

Regardless of the meaning the possible the DKIM-BASE signature protocol has
left itself unprotected.

As my chart shows in my DSAP proposal (submitted to the IETF), at

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html#anchor14

The verifier is going to see signature(s) or none at all and from its
standpoint each has a possibility of 10 different arrangements:

4.2. DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

   From the viewpoint of the verifier, when a message is received, there
   are two basic pieces of signature information to be of interest when
   analyzing the transaction:

   o  Original Party Signatures (OP)

      *  never expected
      *  always expected
      *  optional

   o  3rd Party Signatures (3P)

      *  never expected
      *  always expected
      *  optional

   When the two signature types are combines, the possible policies are
   listed in this following table:

    +=================================================================+
    | op=         | 3p=        | Domain Policy Semantics              |
    |=================================================================|
    | empty       | empty      | No mail expected                     |
    |-----------------------------------------------------------------|
    | never       | never      | No signing expected                  |
    | never       | always     | Only 3P signing expected             |
    | never       | optional   | Only 3P signing optional             |
    |-----------------------------------------------------------------|
    | always      | never      | OP signature expected                |
    | always      | always     | Both parties expected                |
    | always      | optional   | OP expected, 3P may sign             |
    |-----------------------------------------------------------------|
    | optional    | never      | Only OP signing expected             |
    | optional    | always     | OP expected, 3P expected             |
    | optional    | optional   | Both parties may sign.               |
    +-----------------------------------------------------------------+

                  Figure 4: DSAP Message Signing Policies

For the sake of progress, if we set aside 3P policies, we are down to 4
possible OP policies:

 - No Mail Expected by OP (Original Party)
 - No Signing Expected by OP
 - Signing always expected by OP
 - Signaling Optional by OP

It doesn't matter who here thinks if any of these make sense or not. Anyone
can come up with a scenario of when it does or not make sense.  What is more
important is that the VERIFIER will see all the possibilities in the
potential onslaught of DKIM messages.

It would be ideal for the domain to declare what is or not expected in the
mail with purported Domain DKIM markings.

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














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