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

From: Hector Santos <[email-masked]>
Date: Thu, 03 Jan 2008 03:47:15 -0500

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jan 2008 10:43:28 +0100

> update to RFC 4871 to add the SSP=strict|all tag.  Is that the better 

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 ?

 Frank

---

From: Hector Santos <[email-masked]>
Date: Thu, 03 Jan 2008 05:20:28 -0500

> do you propose to integrate SSP wholesale into DKIM, no separate SSP

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:

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 3 Jan 2008 16:37:34 +0100

> 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.

Okay, I got it:  You are talking about cases with a signature
that turns out to be invalid (checking DKIM).  What I had in
mind was a missing (or garbage) signature, where the receiver
never checked DKIM.  Yes, for your cases it accelerates SSP.

> 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.

Now I don't see how "3rd party signature present" can accelerate
SSP for a missing 1st party signature, but that's no problem, I
only need to understand one case where your accelerator works ;-)

Thanks,

 Frank