ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] New issue: Requirement #10 - Invoking SSP -Suggestion to Remove this.

2006-09-26 13:18:14

Hmmm, the subject title is misleading. It is better titled:


  New issue: Requirement #10 - Short circuiting SSP
            - Suggestion to Remove this.


----- Original Message -----
From: "Arvel Hathcock" <arvel(_dot_)hathcock(_at_)altn(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>


10.  The Protocol MUST NOT be required to be invoked if a
     valid first party signature is found.

Hector, doesn’t it say exactly what you want it to say?  It says
that the protocol must not require invocation when valid
first party signatures are found.  It doesn't say "THOU SHALT
NOT INVOKE THE PROTOCOL".  I see nothing that needs to
be changed.

At best this is an optimization implementation consideration and typically,
we try avoided it in protocol designs, especially this one.

Because from one perspective, you are correct only when there is a
PRESUMPTION that the policy is correct and you are trying to short circuit
the lookup if the 1st party signature is valid.

You are presuming the policy is correct, but you made no statement whether
you care whether it is or not, or whether it exist when the 1st party
signature is valid.

First, if that is the case, the document should atleast touch based with the
idea that a valid 1st party signature does not require SSP nor does it care
if 1/2 of the security is broken!

Second, the consideration is more appropriate to be stated as:

  If there is a 1st party signature detected, then
  the implementator MAY perform a DKIM-BASE validation first
  and MAYBE perform a SSP if and only if the 1st party
  signature was invalid.

The problem?

Implementators might create a performance and scalability problem depending
on the failure rate.  The higher the rate, you reach a break-even point
where performing SSP first might provide you the better results without the
DKIM hash verification overhead.

This req #10 is misplaced and if anything it should be part of section 5.1
Discovery Requirements.  Not part of section 5.2.  But DNS optimization is
already implied in section 5.1.  So this req #10 is not useless.

Third, if you look at the DSAP verification Figure 2.0 (below) there are
atleast high potential states or detectable transactions which does not
require any high overhead DKIM verification.

So from engineering standpoint, the optimization favors the SSP lookup at
all times in order to weed out the most highly probable bad-DKIM mail
states.  When this is widely adopted, there is no doubt in my mind, it is a
much better design than what requirement #10 will promote.   So rather than
argue for specific implementation methods, requirement #10 should be removed
simply because based on its technical merits it is flawed.  It is in trouble
in a high-volume of failures.

I will work and play by the decision made by the WG but I can not be
convinced it is the right technical decision.  This requirement will not be
followed in my design simply because it isn't the right one, plus, it
doesn't belong in a requirements document.


     Figure 2: DKIM Signature Authorization Protocol Outline

     +-----------+
     |  PAYLOAD  |
     +-----------+
          |
          v
   +----------------+
   |                |                            +------------+
   | DKIM           |--------------------------->| CONTINUE   |
   | Signature      | UNSIGNED: OPTIONAL         +------------+
   | Authorization  |
   | Protocol       |
   |                |                            +------------+
   |                |--------------------------->|            |
   |                | SIGNED: EXPIRED (1)        |            |
   |                |--------------------------->|            |
   |                | NO MAIL EXPECTED (4)       | FAILURE/   |
   |                |--------------------------->| CLASSIFY   |
   |                | UNSIGNED: REQUIRED (5)     |            |
   |                |--------------------------->|            |
   |                | SIGNED: NOT EXPECTED (6)   |            |
   |                |--------------------------->|            |
   |                | 3P SIGNED: NOT ALLOWED (7) |            |
   +----------------+                            +------------+
          |
          |
       SIGNED
       MESSAGE
          |
          v                                      +------------+
     +--------------+                            | CONTINUE/  |
     |              |--------------------------->| CLASSIFY   |
     |              |    INVALID SIGNATURE       +------------+
     | DKIM         |
     | SIGNATURE    |
     | VERIFICATION |                            +------------+
     | (8)          |--------------------------->| PASS       |
     |              |    VALID SIGNATURE         +------------+
     +--------------+



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


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