[ietf-dkim] Re: New Issue: Threat-00 Limiting the scope of trust
nobody at xyzzy.claranet.de
Fri Feb 3 06:48:10 PST 2006
Douglas Otis wrote:
> 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.
Okay, but it's IMO unnecessary to talk about it in Jim's draft.
He has it already in 1.2:
| The transmission of messages via SMTP, defined in RFC 2821,
| and such elements as the envelope-from and envelope-to
| addresses and the HELO domain are not relevant to DKIM
| verification. This is an intentional decision made to allow
End of story as far as I'm concerned, no need to reiterate it.
> 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!
Of course it's "permitted", receivers and future reputation
services are free to do whatever they like including stupid
things. We can't enumerate all potentially bad ideas, it's
hard enough to catch some necessarily bad ideas.
> The exercise should ensure a signing domain can retain their
> trustworthy status despite the mischief of bad actors.
If it's your intention to get another "I'm no spammer" scheme
without chance that it could be used for the opposite effect
it won't fly. Something signed by a big ISP will never have
the same reputation as something signed by a bank.
And Jim's draft can't be a "how to" for reputation services,
officially that's off topic, declared to be out of scope in
the WG charter. Better stop it before it gets out of hand,
or we're trapped in (un)foreseen ratholes.
> That would allow a bad actor a simple means to destroy
> reputations for signing domains. Tilt- Game Over.
There's a chapter about "replay attacks", all we can do is
warn receivers / reputation services to get ready for this.
And another chapter about zombies "within" an organization:
If those zombies destroy the reputation of a signing domain
that's precisely what we want: Either they get rid of the
zombies, or they get the deserved reputation.
> the signing domain MUST NOT be held accountable for a
> problematic instance of a message.
Signing domains are accountable for allowing the transmission
of a message, and the only interesting case are "problematic"
messages, otherwise nobody cares. There is no 2119 MUST NOT,
receivers will say "stop this enlargement spam or else". Or
phishing / mailbombing / etc.
> The signing domain marking a message as trustworthy is
> assuring the recipient the message is not deceptive in
> _some_ fashion.
Where "some" is either undefined or essentially the same as
"I was stupid enough to transmit this mail, sorry if it's
not exactly what you want".
> Violate the trust, lose the endorsement. Let it happen too
> often, the signing domain will also lose their trustworthy
Yes. I'd hope that a "reputation service" offers more than
black and white, but also several kinds of grey in between.
> Why convey an indication of trustworthiness for messages
> from bad actors? Unless the domain is known, it should not
> be assumed to be trustworthy.
Domains like spamcast are known. For ISPs with 1,000,000 or
more customers it's only natural that one (?) of them tries
to start a new career as baby-spammer, daily. Not counting
the zombies, discussed in another chapter of Jim's draft.
>>> 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.
When I wrote "not necessarily" what I had in mind was Ironport
with their combination of Senderbase and SpamCop.
>> The MSA signs, not the laptop.
> The MSA or perhaps the MUA, from my understanding, can sign
Okay, the latter is new for me, but let's say it's possible.
Then I fail to see why a mobile MUA should be necessarily
more dangerous than other MUAs. Anything with a Win-logo on
it is threatened, whereever it is. All they need is a say
Sony CD and "oops, did it again".
> few domains can fully trust all users with access to their
> outbound servers.
Then let them partition their users in signing subdomains,
or let them use different subdomains for groups of similar
AUTH methods. It's their problem. If you want the aspect
of different classes of users / AUTH methods as new chapter
it's okay, but I'm not yet convinced by your "flag" idea.
More information about the ietf-dkim