[ietf-dkim] DKIM SSP: Security vulnerability when SSP record does
dotis at mail-abuse.org
Thu Aug 18 09:57:27 PDT 2005
On Aug 18, 2005, at 8:59 AM, Jim Fenton wrote:
> Earl Hood wrote:
>> On August 17, 2005 at 22:07, Jim Fenton wrote:
>>>> When a DKIM verifier, "V", receives the message, the signature
>>>> validates cryptographically (remember, the signer public key is
>>>> retrieved from EXAMPLE.com). The verifier now checks the OA SSP by
>>>> query example.org's nameserver. The query returns no record
>>>> What verification status should V return?
>>> V should say that the message is signed by a third party.
>> I think this is dangerous behavior.
>> What value is there to the recipient stating that the the message was
>> signed by a third-party. DKIM should not facilitate spoofing, and
>> the example I gave, spoofing is the intent. There is a danger that
>> giving _any_ positive verification of the signature can legitimize
>> the message in the recipient's mind.
> A third-party signature is a lot weaker assertion than an OA
> signature, unless you know something about the third party.
The risk would be related to how this assertion is perceived by the
recipient. If all they see is a highlight or a DKIM verification
icon, then it would be difficult to discern third-party from OA. In
the general case, there would be nothing seen. By the way, is the OA
algorithm still being considered? There was some talk about making
this only the From rather than tossing it to the Sender when there
are multiple From addresses. A concept I am sure will confuse many
recipients as well.
>> If no SSP record is defined, "never signs" should be assumed (note
>> the current SSP draft does support a "never signs" policy). This
>> prevent malicious domains from exploiting any "trust" DKIM generates
>> in order to spoof identities.
> Actually, the current SSP draft supports a "never sends email"
> policy, which is quite different.
This concern is related to a goal of ferreting out obviously spoofed
messages for the naive user, based upon domain-wide assertions. By
dropping this goal presently, these issues become immaterial. This
is a very difficult goal to achieve due to many tactics that remain
available to dodge protections attempted by the various possible
algorithms. (a long row to hoe.)
DKIM could take the view that simply making the "accountable domain"
visible by the MUA will eventually deal effectively with this naive
user issue. Until this information is displayed, the "other" goals
of DKIM are being met. In other words, no additional icons or
notations should be added without displaying the "accountable domain".
The "accountable domain" still provides an effective means for basing
acceptance. Some header insensitive techniques could permit
rejection of messages that fail to meet demanded criteria and would
be easier to defend.
(Assume header insensitive as this does _not_ consider what the
naive user sees.)
(Also assumes a signature flag that limits the addition of Sender &
1- Employs DKIM
2- Employs DKIM universally
3- Allows TP signing
4- Allows sub-domain TP signing
5- Disallows all TP signing
6- Never sends email
It would seem counter productive to for assertion 5 to be the default
taken as this would greatly discourage larger ISP from universally
signing all outbound mail. For those where this would matter, then
making the assertion should be required.
>> Someone at example.org may not know what EXAMPLE.com does, so
>> they should not be adversely affected by the application of DKIM
>> by EXAMPLE.com.
> Exactly. Are you suggesting that the default should be:
> (1) Treat any signature from the OA (example.org) with suspicion, or
> (2) Treat any signature on a message from the OA with suspicion ?
> If it's (2), it means that domains that haven't deployed DKIM that
> send through mailing lists to domains that are checking SSP would
> have those messages marked as suspicious.
Here the trade-off is rather clear. The restrictions on TP
signatures is related to combating phishing exploits which affect
only a minority of domains. The majority of domains should be
willing to allow their messages to be "spoofed" (third-party
signatures) out of sheer convenience.
> I don't have nearly as much trouble with (1), but it only helps
> with marking messages with invalid signatures as suspicious
> (presumably attackers can't attach valid signatures). But if a
> domain is checking SSP, wouldn't they be checking the signature as
What does suspicious mean to the recipient in this case?
>> Also, DKIM does not support the benevolent scenario you mention
>> very well. Since the validity of a signature is determined by the
>> OA's SSP, a mailing list cannot add a signature if the SSP forbids
>> third-party signing (which may be common for security reasons).
> It depends on how one interprets a message, given an EXCLUSIVE SSP,
> with a third-party signature as compared with a message with no
> third-party signature (and presumably no valid OA signature in
> either case). One way to look at this is to let the mailing list
> sign everything, but then the verifier just ignores the out-of-
> policy third-party signature. Another way is to require the
> mailing list to consult SSP, and sign only those messages that
> permit third party signatures, and for the verifier to treat
> messages with out-of-policy signatures more harshly than those that
> don't. I favor the former approach, because it makes things
> simpler for mailing lists (why check SSP at every step?) and
> because it puts the decision in the hands of the recipient's
> verifier because it's really the recipient we're serving.
Another view would be for the mailing-list to leave all signed
messages intact. There would then be no added overhead groping for
SSPs. The mailing-list may adopt a convention where new headers
replace the technique of message modification.
More information about the ietf-dkim