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

[Hector Santos]

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