On Fri, 2006-02-03 at 04:05 +0100, Frank Ellermann wrote:
Douglas Otis wrote:
Therefore, a DKIM signature precludes an assessment of the
number, the return-path, and the intended recipients
associated with the signing domain of a message.
DKIM does not preclude an assessment of the envelope and/or
sending IP with other means.
Of course other identifiers can be assessed. This statement however
indicates assessments associated with the signing domain can not include
elements of the message envelope.
Omission of the message envelope therefore necessitates a
different evaluation paradigm than that of a typical
"opt-in" criteria when assessing the trustworthiness of
the signing-domain.
That's not the case.
A verified signature is independent of the message envelope parameters.
Unless the signing-domain is assessed separately, a bad actor could
easily ruin the reputation of a signing domain. This can not be
permitted!
The DKIM signature offers no assurances related to number of
messages, the intended recipients, or the return-path, which
are often criteria used to assess abusive email sources.
That will be dealt with before the DATA by other methods.
Yes, but these other methods should not affect the reputation of the
signing domain.
Regardless of the number of messages, and those sent to
recipients that never expressed a desire for their receipt,
such behavior can not be attributed to the signing domain.
Of course it can. Originating or forwarding spam, anything
goes, add signature, and be damned as spammer. That's the
whole purpose of this exercise.
The exercise should ensure a signing domain can retain their trustworthy
status despite the mischief of bad actors. A signing domain can not be
damned based upon a message envelope taking it where it does not belong.
That would allow a bad actor a simple means to destroy reputations for
signing domains. Tilt- Game Over.
The assurance provided by the DKIM signature is strictly
limited to the initial domain and the nature of the
message's content.
The assurance is "I sent this mail to you, don't bother to
study timestamp lines, here's my signature, block me if I'm
a spammer".
A signature indicates the message originated from within the signing
domain. A signed message may _not_ indicate for whom the message was
intended. Especially in those cases where the RCPT TO is not discovered
in the message, the signing domain MUST NOT be held accountable for a
problematic instance of a message.
Messages of a criminal nature, encompassing a deceptive
header field, or offering misleading links provides the
limited basis for assessing a violation of trust.
That isn't the case, a signing entity cannot determine the
"criminal nature" of a message, it's a script, not a lawyer.
It also can't identify deceptive header fields, let alone
study URLs in the body.
Exactly. The signing domain marking a message as trustworthy is
assuring the recipient the message is not deceptive in _some_ fashion.
This assurance would not be based upon some script or email-address, but
upon who is allowed to receive their endorsement. Violate the trust,
lose the endorsement. Let it happen too often, the signing domain will
also lose their trustworthy status.
a DKIM signature should reduce the errors involved with such
an evaluation of individual messages.
Sure, black hat signed it ? Score -100. Working as designed.
It is unlikely there will be methods that safely ensure bad actors can
be block-listed. In the cases where they can be, it is likely they're
already one step ahead. DKIM will likely need to start by using a list
of known good actors. Perhaps listing domain with a server certificate
from trusted CAs could be a starting point. Violate the trust, and then
be removed from the list. With such an initial requirement, there will
be individuals that can be held accountable.
Following a message evaluation, any resulting assurances
conveyed to the recipient should preclude those messages
from unknown signing domains which might be controlled by a
bad actor.
ACK, anything STRONG without valid original DKIM signature was
already rejected at this point.
This conveyance of assurances should exclude even for those email-
addresses within the signing domain (where policies would not be
checked) but the trustworthiness of the domain is unknown.
a vetted list of trusted signing domains should qualify
assurances conveyed to the recipient.
s/trusted// Nothing's wrong with a vetted list of white, grey,
and black hats.
Why convey an indication of trustworthiness for messages from bad
actors? Unless the domain is known, it should not be assumed to be
trustworthy.
A reputation system will be unable to respond fast enough
to deter abuse of a "trusted" message status.
Not necessarily.
As you have already indicated, there is no simple system for assessing a
violation of trust based upon DKIM signed messages. Many phishing
attacks start and finish within hours, and there are thousands of domain
names that can be used for this activity.
Marking bigbank.com as trusted will allow recipients an easy means to
spot bad actors using biqbank.com or accounts-bigbank.com that should
never obtain the trusted marking. Once the message can be marked
trusted, then perhaps also indicate whether the email-address is within
the signing domain.
A safe indication conveyed to a recipient would be an
assurance that a message source is from a "trusted"
signing domain.
Or from a known grey / black hat. DKIM is about valid or
invalid signatures, not about promoting dubious bulk mailers.
Bad actors will not have any difficulty creating perfectly signed
messages. Using trusted domain lists is definitely less expensive than
expecting each domain to acquire all possible look-alikes.
Unfortunately, the industry has already been rather misleading about the
use of modified domain names. :-(
Even one signed message can be replicated a billion-fold
and sent rapidly anywhere by an army of zombie computers.
No problem to say something like that, but not more than once.
This was to illustrate how critical it is to ensure only trusted sources
have access to keys carrying a trusted status.
There should be a method, perhaps with a flag within the
DKIM key, to indicate whether the signing domain itself
considers the source of the message to be trustworthy.
The D in DKIM doesn't stand for "Do what I mean", they'll get
an average reputation for mails signed by them. If they don't
like this let them create signing subdomains.
If reputations were based upon numbers as determined by messages
directly obtained from the MTA, then talking about averages may make
sense. When one considers the army-in-the-middle situation, a 1%
problem replayed can become 1000%.
A signing domain may consider private keys within traveling
employee's laptop at too great of risk to allow the key to
be evaluated as trustworthy.
The MSA signs, not the laptop.
The MSA or perhaps the MUA, from my understanding, can sign messages.
In the case of the traveling employee while away from the
office, their messages would not be marked as trustworthy.
That's mostly unrelated to DKIM, implementation details of
the MSA. If it's paranoid let it use different subdomains
in its signatures.
Use of sub-domains would tend to create less trust and not more.
Changing the appearance of the domain name will not be understood by
many people, and may cause them to be more easily mislead by hyphenated
names rather than period separated. It is also likely that few domains
can fully trust all users with access to their outbound servers. Again,
just one signed message is all that is needed for a fair amount of
havoc. Otherwise, without constraining this exposure, reputations
services will have trouble keeping up. By marking keys trusted, this
will allow the signing domain a means to limit the extent of their
exposure, and to reserve a trusted status for where it is most needed.
DKIM and vetted domains can prevent phishing exploits. That should be
enough.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org