ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-15 16:41:44

On Aug 15, 2005, at 3:40 PM, Arvel Hathcock wrote:

This means that it is providing an assurance that the message
contents, including originating address fields, are authorised.
If the signing party is unwilling or unable to provide this
assurance, then they should not apply a signature.


That would be wonderful but the problem is that we can't count on the signing party playing along with that restriction. Bad actors will be happy to sign using THEIR domain while placing paypal or ebay (or YOUR domain) in the FROM. We will have gained little other than the eventual knowledge that signatures from the bad actor's domain are disreputable. That's good, it's something we haven't had before (via signature mechanisms anyway) but what's required by verifiers is specific action when the signature does not match the FROM.

Aren't we attempting to address forgery of domains in the originator header? That's the first sentence of the proposed charter. We needn't confound this goal in my opinion with the smoke-screens of solving "phishing", "spam prevention", or, God forbid, the spectre of "figuring out who sent the message".

There remains several problems when making a claim of anti-forgery. Clearly, there would be a different domain being trusted, but some are not happy to stop there.

Making an anti-forgery claim spills over into the local-part. With this, there are also issues regarding pretty name presentation, and which header is used to obtain such a policy, and which header is seen by the recipient, and which is understood as being significant in this process. Anti-forgery implies DKIM does something about the local-part of the mailbox-address. Adding cruft in an attempting to shore up these many issues, only hurts the chances of DKIM becoming widely deployed. If you _must_ know the author of the message, use S/ MIME or OpenPGP. The complexity involved in drilling down to the author is a significant impediment for deployment.

Not calling this assertion an anti-forgery or anti-phishing provision would be more helpful. Call this a provision for constraining the acceptable signing domain based upon the From mailbox-domain. This does _not_ prevent forgery or phishing and says nothing about the local-part. Whatever protections that may exist are completely beyond the control of DKIM, and reside completely within the signing domain. There is no way for the recipient to know, beyond the trust they have in the signing domain.

Upon reading the SSP draft, Earl appears to be right. The pseudo code is not clear about what is allowed in this regard, as it seems to make provisions optionally different than the current draft. Signing domains matching the From mitigate the SSP check, however the algorithm regarding the significant domain for the policy uses the OA algorithm, unless this is being changed in a subsequent draft. The SSP is based upon the "Alleged Sender" (Originator Address). It there an write-up that describes this process yet?


See SSP:

----
In the absence of a valid DKIM signature on behalf of the "From" address [RFC2822], the verifier of a message MUST determine whether messages from a particular _sender_ are expected to be signed, and what signatures are acceptable.
...
2.1 Originator Address

The email address in the "From" header field of a message [RFC2822], or if and only if the From header field contains multiple addresses, the email address in the "Sender" header field.
...
• An "Alleged Sender" is the Originator Address of a message received by a verifier; it is "alleged" because it has not yet been verified. • A "Sender Signing Policy" (or just "policy") is a machine- readable record published by the Alleged Sender which includes information about whether that sender signs all, some, or none of their email. It must be considered together with the "key" records, which advertise the public keys associated with the Alleged Sender.
----

-Doug
_______________________________________________
ietf-dkim mailing list
<http://dkim.org>