On August 18, 2005 at 08:59, Jim Fenton wrote:
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.
Correct. I noted that "never signs" is not available.
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?
You are operating under the assumption that SSP records do not need
to be available for those that want message signing. I think this
is a mistake. SSP is critical, and if an entity wants allowing
signing of their messages, they should be explicit in what the
signing policies are. Trying to imply desired behavior is generally
poor practice.
So for (1), OA should define appropriate SSP records for signing.
Verifiers should not imply policies.
For (2), yes. The problem is that DKIM binds signatures to the
OA (rfc2822.From). If DKIM supported alternate binding semantics,
OA SSP will not be an issue, and an entity like a mailing list
can sign all outgoing messages without conflicting with OA SSP.
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.
Then what incentive exists for a 3rd-party to devote resources to
DKIM signing messages if verifiers will ignore them?
You are viewing things within the constraints of how DKIM is currently
defined. I'm trying to point out that view may have some problems.
I am not comfortable, from a security and auditing perspective, that
a verifier will just ignore signatures on a message. An existence of
a signature means something, and blindly ignore the "invalid" ones
(from an OA SSP perspective) could possibly lead to exploitation,
and serve a disincentive to 3rd-parties to sign messages.
Another way is to require the mailing list to consult SSP, and sign only
those messages that permit third party signatures,
This has been mentioned before on ietf-mailsig. There appeared to
be valid justifications that all signers checking the SSP before signing.
and for the verifier
to treat messages with out-of-policy signatures more harshly than those
that don't.
If DKIM supported binding semantics that did not bind to the OA,
out-of-policy signatures may not be a problem, and probably beneficial.
Do you see value in an entity signing a message (or parts of it) just
to indicate, "here is what I saw" without binding itself to the OA?
From a recipient's perspective, the most important signature will
be the one bound to the OA, the one that indicates that state and
contents of the message when first introduced into the email system
(will ignore subtleties about when this "first" signature is done
and by whom and if the signature accurately reflect the contents of
the authored message).
Other (valid) signatures may not be presented at all to the end
recipient, but function for audit and forensic purposes, something mail
administrators may find useful when dealing with questionable messages.
The information could be displayed to (savvy) end recipients, but
only to show the transmission path of the message.
Such information can be useful to show when a signature "breaks"
in the transmission path (either non-maliciously or maliciously).
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.
I think ignoring signatures is not good policy. This gives wiggle
room to malicious entities. For example, a bad actor can invalidate an
existing signature and add in their own, something worth doing if an OA
is uncareful and allows third-party signing (3rd-party signing policy
does not allow one to list the 3rd-parties, it is all or nothing).
--ewh
_______________________________________________
ietf-dkim mailing list
http://dkim.org