ietf-dkim
[Top] [All Lists]

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

2008-01-03 01:54:19
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

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

<Prev in Thread] Current Thread [Next in Thread>