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
_______________________________________________
ietf-dkim mailing list
http://dkim.org
