SSP is ability to indicate policy for email address, i.e. when you see address in from you can check to find if emails from that address are supposed to be signed. If you only check policy record when you see a signature - this pretty much breaks the reason for having such policy record in the first place.
On Mon, 30 Jan 2006, Tony Hansen wrote:
My comment here is really about the relationship between DKIM and the SSP: what Hector is describing below implies to me that we need to know up front whether or not an SSP should be applied. This can be accomplished in several ways: 1) always look for the SSP, as Hector suggests; 2) add information to the DKIM DNS record to indicate that the SSP should always be looked for; 3) incorporate the SSP information into the DKIM DNS record; or 4) some other ways I'm not thinking of at the moment. Of the first three, I'd lean towards #2. Tony Hansen [EMAIL PROTECTED] Hector Santos wrote:Suggested correction to TA: Add a new attack item: Inconsistent Signature vs. Policy Attacks Impact: High Likelihood: High If a new column "Detection/recovery" is added as suggested in a previous TA review comment, then this would change to: Inconsistent Policy Attacks Impact: Low Likelihood: High Detection/Recovery: High Background reasoning: Currently the SSP draft intent is to only apply SSP against messages lacking a signature. If a valid signature is found, then SSP is not necessary. [Note: if this understanding is incorrect, please correct it.] Ironically, this SSP draft specification would present the highest and more probable threats or occurrence of the DKIM/SSP proposal. By following the draft specification, there will be many loopholes. Example loopholes: 1) A message is signed, but the SSP indicated a "o=." (No mail expected from domain). 2) A message is signed, but the first party domain has no declaration of a signing policy. Currently, the SSP draft has no specification to expose a "No signature expected" policy. Instead, the NXDOMAIN DNS result for a SSP will result with a default o=~ policy (optional signing by any party). 3) A message is signed by a 3rd party, but the SSP indicated a o=! policy where the original domain signature is required, and a 3rd party signature is not expected but allowed to be present. Note: The o=! policy can be a defined a "near exclusive" policy, but it is not an absolute exclusive policy consideration. 4) Although there is no current SSP specified in the draft to declare an optional original domain signature and no 3rd party signing expected the policy exist for this scenario to occur. These signed mail "NO need for SSP" attacks should be consider to have a high potential occurrence with direct attacks and indirect attacks. Direct attacks would be bad actor attempts to exploit compliant DKIM/SSP systems. Indirect attacks would be bad actors attempts to exploit non-compliant DKIM/SSP and rely in "social engineering" exploits. With indirect attacks, bad actors will not emphasize on protocol correctness. These attacks can be detected if the SSP is checked against the domain whether the message is signed or not. This will lower the risk, the uncertainty of bad attack exploits and hence, lower the impact of these high probably attacks -- Hector Santos, Santronics Software, Inc. http://www.santronics.com
_______________________________________________ ietf-dkim mailing list http://dkim.org
