ietf-dkim
[Top] [All Lists]

[ietf-dkim] draft-ietf-dkim-threats-00

2006-01-24 13:52:19
---[A: Misstatement of the DKIM mechanism.]
,---
| 1.  Introduction
|
| DomainKeys Identified Mail (DKIM) [I-D.allman-dkim-base] defines a
| mechanism by which email messages can be cryptographically signed,
| permitting a signing domain to claim responsibility for the use of a
| given email address.
'---

A verified signature does not indicate that the signing domain is claiming responsibly for some email-address found within the message. It is not a reasonable practice for a general access provider to inject a Sender header just to meet this expectation. This has already caused problems and should be avoided.

This should read:

: DomainKeys Identified Mail (DKIM) [I-D.allman-dkim-base] defines a
: mechanism by which email messages can be cryptographically signed,
: permitting a signing domain to be held accountable for the message.
: When an email-address contained within the message is also within
: the signing domain, and noted within the 'i' parameter, the signing
: domain may also be held accountable for verifying the use of the
: email-address conforms to their policies.



---[B: Limited information in a critical section.]
3.2.  Use of Specific Identities

As per a prior email, this section needs additional detail. While there are separate sections expanding upon this issue, references should be made by this section. I will be happy to try again using references to other sections.



---[C: Unreasonable estimate of impact from a highly probable exploit.]
,---
| 4.1.  Attacks Against Message Signatures
|  ...
| Signed message replay                       |   Low  |    High    |
'---

This should read:

: Signed message replay                  |  Very High  |    High    |

How was this problem rated? Any large domain has a continuous background of abuse being sent. In some cases, this abuse may represent tens of thousands of compromised systems. Any list-server is also prone, as there is no practical means to screen participants or expect effective outbound filters when the number of messages do not reflect the overall traffic until used in the replay. Out of the millions of valid users within these domains, rate limiting has ensured these abusive systems represent a smaller percentage of the overall outbound email in most cases. When used in conjunction with a replay strategy, rate limits will not remain effective, and yet the signature still remains valid.

Once the DKIM signature has any acceptance value, expect this problem to become paramount.



---[D: Overlooking a practical solution while also recommending a highly unfair solution.]
,---
|4.1.4.  Chosen Message Replay
|
| ... One approach to this problem is for the
| domain to only sign email for clients that have passed a vetting
| process to provide traceability to the message originator in the
| event of abuse.
'---

Unless there is an expectation that individuals obtain their own certificates from a trusted authority, individual reputations on a cost-free email-address would be completely futile and unfair as DKIM does not necessary verify the valid use of an email-address anyway.

Another strategy not mentioned would be establishing a practice where incoming signatures are overlaid with verification results. Recommending an overlay practice should replace recommending the impossible of establishing the reputation for individual email- addresses. There is _no_ means that would be fair without using individual CA certificates. The recipient domain can be fairly held accountable for ensuring that incoming signatures are protected using signature overlays. The vetting process would be made when deciding whether it would be _safe_ to sign a message destine for a particular domain.

Replay abuse can not assume the email-address associated with the message had participated. There is _no_ fair means for holding an email-address accountable! A domain or IP address must always be made accountable with respect to any reputation scheme!

-Doug








_______________________________________________
ietf-dkim mailing list
http://dkim.org

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