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>
|
|