ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: New Issue: SSP Restrictive Policies Recommendation for an RFC 4871 update

2008-01-03 03:27:51
Frank Ellermann wrote:
Hector Santos wrote:
If we don't wish to consider this now, I can see an I-D proposing an update to RFC 4871 to add the SSP=strict|all tag. Is that the better approach?

I still don't see how adding the SSP info to DKIM records could help
receivers confronted with an unsigned mail.  Why would the receiver
prefer to get the DKIM info when what he needs is the SSP info ?  Or
do you propose to integrate SSP wholesale into DKIM, no separate SSP
at all ?

The sub-steps provided in the original messages explained the logic.

In SSP-01, Step 1 has:

   1.   If a valid Originator Signature exists, the message is not
        Suspicious, and the algorithm terminates.

This means that the signature was verified via DKIM-BASE. It also means the DKIM key record was obtained and all information points to a 1st party signature.

If we continue beyond step 1, this implies we have the following states:

   a) valid 3rd party signature, or
   b) no signature (which can be from a broken signature).

So step 2 and 3 deals with the SSP discovery process in order to address these two states.

The proposal is this:

We can reduce (not eliminate) step 2 and 3 by short circuiting the steps if the DKIM key record obtained in step 1 contained the SSP policy information; SSP=strict|all

So in step 1, we can add the following sub-steps:

  1a) If we have a valid 3rd party signature or no signature resulting
      from a failed DKIM-signature validation, and the key record
      contains a tag SSP=strict, then the message is Suspicious and
      the algorithm terminates.

  1b) If we have no signature resulting from a failed
      DKIM-signature validation, and the key record contains
      a tag  SSP=ALL, then the message is Suspicious and the
      algorithm terminates.

The whole point is that under strict DKIM/SSP operations there is only one party involved and no other party or unsigned messages are expected and under the ALL policy, there is only 1 state the message can be in - a signed state.

In both cases, we short circuit the need to do a SSP discovery by adding an optional DKIM-BASE SSP= tag option to DKIM-BASE key records.

If the message is not signed and/or the failed DKIM signature key record contains no SSP= tag, then the verifier would proceed with the current recommended steps 2 as stated in SSP-01.

A point to consider is that the proposal deals a Negative Classification only, hence bad guys will not have any incentive to exploit.

If the strategy goal of DKIM-BASE is to get "everyone" to consider DKIM signatures, then this includes the high value domains who will want to use this technology in exclusive, highly restrictive operations. This is where the highest benefits and payoff is obtained in utilizing this technology.

Therefore, having a SSP=restrict|all in the DKIM key record is undoubtedly a massive improvement in the overall model, reducing DNS concerns, simplifying the SSP protocol while still offering the same ideas DKIM+SSP attempts to offer without introducing any new threats.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

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