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

On Feb 3, 2006, at 6:48 AM, Frank Ellermann wrote:

> 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.
While this clarifies the verification process, this does not stress  
the importance of assessing the signed portion of the message  
separately.

> > 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 draft should be able to say what is considered permissible.  Many  
that will attempt to use DKIM to abate spam, which is like using  
tweezers to remove a bolt.  It won't work and will break the tool.   
Misapplying assessments enables mischief by bad actors damaging the  
trustworthiness of otherwise innocent signing-domains.

> > 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.
This is not about self declarations of "I'm no spammer".  This would  
be looking for the union of a list of "trusted signing-domains" held  
by the recipient, with a list of "trusted sources" held by the  
signing-domain.  This union can safely enable acceptance criteria or  
message markings.  Without this mechanism, DKIM would not be as safe.
Unless there is a method for the ISP to constrain what is considered  
trustworthy, it would be impossible for the domain to establish any  
trust whatsoever.  Even a bank would be prudent to consider their  
exposures with respect to who has access to their outbound servers.   
The trusted key concept limits their exposure without increasing the  
number of email-address domains being used.

> 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.
This is not about how a trust violation is determined or reported,  
which I agree represents concerns for a different WG.   This is  
specific to a DKIM signed message regarding the scope of the message  
that can be safely assessed.  This also considers a need to further  
limit the scope of trust for sources within the signing-domain, as  
many domains contain users that can not be adequately vetted.  The  
introduction of the Threat document also clarifies that these  
assessments to be made.  It seems appropriate to consider the scope  
of the assessment as it pertains to DKIM, how this assessment  
provides threat avoidance, and the threats related to the assessments  
where the scope is misapplied.

> > That would allow a bad actor a simple means to destroy reputations  
> > for signing domains.
> There's a chapter about "replay attacks", all we can do is warn  
> receivers / reputation services to get ready for this.
DKIM could also provide an essential/simple tool for limiting the  
exposure to this looming problem.

> 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.
While I agree with the motivation, there needs to be a strategy for  
tackling the problem as it currently exists.  Zombies can destroy the  
trust of even innocent signing-domains when "opt-in" criteria is used  
as an assessment basis.  Prohibiting this assessment basis however  
means using DKIM to control acceptance will be painful.  A convention  
for permitting the tracking of sources offered by DKIM, combined and  
reporting and revocation may slowly beat down the problem.  For  
effective reporting, the signing-domain, and not the email-address  
policy, needs to offer the reporting vector.  This is going to be a  
long slog.

> > 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.
As it is now, many receivers want to identify problematic domain's IP  
addresses to _white-list_ them.  This is because a percentage of many  
large ISP's traffic is reported on various block-lists.  Using DKIM  
in this manner would be foolish.  Many may be disappointed who expect  
DKIM to offer a solution for this problem. :-(

> > 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".
As far as an assessment is concerned, the "you" can not be assumed to  
apply to the signing-domain.  If the domain signed the message and  
marked it as coming from a trusted source, but a link within the  
message was bait for a man-in-the-middle attack, then the signing- 
domain has violated a trust.  A message sent to the wrong recipient  
_must not_ be considered a problem for the signing-domain.

> > Violate the trust, lose the endorsement.  Let it happen too often,  
> > the signing domain will also lose their trustworthy status.
> Yes.  I'd hope that a "reputation service" offers more than black  
> and white, but also several kinds of grey in between.
Perhaps, but ratings would be beyond the scope of what is relevant  
for DKIM.  An assessment could be reasonably applied only after  
suffering a fair amount of expense.  This is not something to be used  
to assess each and every message from an ISP. :-(

> > 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.
Exactly.  But the administrator within that domain should be  
trustworthy and should be able to have their messages acknowledged as  
trustworthy.  This will be important when customers start seeing  
messages from their provider indicating they have problems and need  
to take action X.

> When I wrote "not necessarily" what I had in mind was Ironport with  
> their combination of Senderbase and SpamCop.
This was about starting with a vetted list of trusted domains, valid  
for this example.

> > The MSA or perhaps the MUA, from my understanding, can sign messages.
> 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".
When the mobile MUA carries a copy of the private key to allow signed  
messages when there is no access to the home office, this would  
represent a key that would be less trustworthy due to its exposure.   
Perhaps they travel to foreign countries or hotels with crazy firewalls.

> > 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.
The use of the trusted/non-trusted keys provides a transparent method  
of introducing security via DKIM.  Your solution will not be  
transparent, will disrupt the normal email-addresses in current use,  
and will create greater confusion further endangering the recipient,  
who DKIM is attempting to protect.

-Doug



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