ietf-dkim
[Top] [All Lists]

[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust

2006-02-02 20:15:12
Douglas Otis wrote:

Often "block-listing" is a method of ostracism used for
email sources that have been identified as violating a
trust.

s/a method of ostracism//

Email sources being block-listed often have not adhered
to an "opt-in" criteria for the distribution of bulk email.

There are many reasons for black-listing, irrelevant for DKIM.

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.

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.

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.

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

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.

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.

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.

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.  

A reputation system will be unable to respond fast enough
to deter abuse of a "trusted" message status.

Not necessarily.

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.

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.

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.

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.

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.
                           Bye, Frank


_______________________________________________
ietf-dkim mailing list
http://dkim.org