Earl Hood wrote:
On August 17, 2005 at 22:07, Jim Fenton wrote:
Let's say example.org knows nothing about DKIM or has not adopted
it yet. EXAMPLE.com is operated by questionable folks, and they
know example.org does not have any SSP records defined. EXAMPLE.com
defines _domainkey.EXAMPLE.com records to contain valid signer
public keys.
EXAMPLE.com sends out messages signed by EXAMPLE.com, but places
an example.org address in the rfc2822.From.
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 available.
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.
If no SSP record is defined, "never signs" should be assumed (note
the current SSP draft does support a "never signs" policy). This will
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.
Care must be taken to insure DKIM does not facilitate malicious
behavior.
After all,
it's possible that someone at example.org uses a mailing list hosted by
example.com, which might have a good reason to sign a message.
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.
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 well?
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.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org