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

Hector Santos hsantos at santronics.com
Thu Jan 3 00:47:15 PST 2008


Understanding the sensitive nature of this, I will try to propose this 
delicately.

Proposal:

DKIM signing domains who wish to implement restrictive signing policies 
such as DKIM=STRICT or ALL and have a desire for verifiers to 
aggressively handle this policies, SHOULD consider adding a SSP=STRICT 
or SSP=ALL tag to the DKIM-BASE key record.

The goal is to reduce verifier DNS overhead by short circuiting the SSP 
discovery steps 2/3 which is only necessary when the transaction state is:

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

The following sub-steps should be added to step 1:

   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.

If no SSP= tag is present in the DKIM key record, the verifier should 
continue with step 2.

Discussion:

I believe Jim agreed that this would "reduce the number of SSP lookups a 
bit" however, he felt this may be an implementation or deployment 
consideration and/or we might review this after the initial SSP-01 
specification is completed.  He also correctly indicated with a less 
concern, there would still be a need for an SSP record and now a dual 
management of SSP; A SSP= tag for the DKIM key record, and a SSP record 
  itself.  The policy  in both places must match.

I agree with all Jim's point.

However, in the effort need to make SSP viable, acceptable, less 
complex, its usefulness well understood for consideration, and 
hopefully, we can get it to a point where everyone is the same page, 
then considerations like this should be put on the table now.

If many domains (which I believe they will be many) will be considering 
DKIM with the intent to operate in strict or all signing mode, we could 
lose the opportunity to correctly and efficiently deploy the combination 
of DKIM and SSP to everyone's benefit and satisfaction.

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?

-- 
Sincerely

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



More information about the ietf-dkim mailing list