[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]
Hallam-Baker, Phillip
pbaker at verisign.com
Thu Jan 12 08:18:26 PST 2006
I agree with Stephen here.
The term 'authorization' is part of the whole permissions based approach
to security. DKIM is not a permissions based security protocol, it is an
accountability based protocol.
The sender is not 'authorizing' a message, it is CLAIMING OR DENYING
RESPONSIBILITY for the message.
The policy enforcement and policy decision points are BOTH on the
recipient side. Using the language of permissions leads to confused
thinking. People start to think that the point of a policy record is to
tell the recipient what to do, they start to think that the sender has
'rights' to dictate what the recipient does with the information
provided.
I get particularly worried when people start forgetting that the
underlying assumption here is that the sender cannot be trusted
a-priori, only SOME senders can be trusted.
The accountability based language, in particular considering claims or
denials of responsiility avoids this problem. Implicit in the language
of claims or denials is the fact that THEY ARE NOT NECESSARILY TO BE
BELIEVED. So even if an email sender denies having sent a ton of spam,
that denial is not necessarily to be believed.
The language of authorization is embedded in the permissions based
approach to security, an authorization is a decision, it is not a piece
of data to be considered in context.
The permissions based approach is certainly a valid approach to security
and there are certainly many applications that require a permissions
based approach. But it is only compatible with a subset of security
problems, the problems where the rules are 1) known in advance 2)
describable in objective terms. This necessarily limits the scope of the
permissions based approach to tasks where the number of parties is
closed and the assets being protected are relatively valuable and the
consequences of a single failure is very great.
We are dealling with problems that result from the scale of the
Internet. We are trying to control an environment with a billion users.
The consequences of individual failures is not great but the cummulative
cost of large numbers of failures (1000 spams a day) is very
significant.
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Stephen Farrell
> Sent: Thursday, January 12, 2006 9:18 AM
> To: Douglas Otis
> Cc: IETF-DKIM
> Subject: Re: [ietf-dkim] [Fwd: I-D
> ACTION:draft-fenton-dkim-threats-02.txt]
>
>
> Doug,
>
> Thanks again for trying to be brief. I think it did make you
> easier to understand.
>
> > Terminology:
> > The terms "open-ended" and "closed" authorization are defined as:
> >
> > A basic function of email authorization referenced by
> way of an
> > identity is to influence the acceptance or rejection
> of a message.
> > The term "closed" indicates acceptance is based upon
> the identity
> > being found within a defined set of identifiers.
> When acceptance
> > does not require that the identity be contained
> within a defined
> > set, this is described as open-ended authorization. This
> > definition is not altered by the rating of messages
> once they are
> > accepted.
>
> I don't think the term authorization is being properly
> applied there. To me at least authorization is what's
> happening when a policy enforcement point uses a policy
> decision point to get a yes/no answer about some requested action.
>
> For example, I could imagine a totally separate set of
> technologies being used to decide whether or not a given
> message can be delivered to a certain recipient (say if the
> message has a security label like "restricted"). In such
> cases it'd be much more natural to talk about something
> having authorized the message.
>
> I think talking in terms of sender signing policy is clearer
> (in the abstract I mean, not only nor exactly as currently
> specified in the SSP draft).
>
> > SSP 'o=' Qualifiers:
> > "~" Signs some (open)
> > "-" All signed & allow other signatures. (open)
> > "!" All signed. (closed)
> > "." Never sends mail. (closed)
> > "^" Check user specific policy (deferred)
>
> The open/close/deferred distinction makes sense I guess.
>
> Restated: "Policies can be open or closed. Open policies
> define a set of conformant messages and are silent about
> other messages. Closed policies define the set of conformant
> messages and other messages do not conform to the policy."
>
> > 3. SSP Related Threats
> >
> > 3.1 Risks associated with the misuse of "open-ended" authorizations
>
> That'd be better put as "Consequences of "open" sender
> signing policies"
> IMO. "Risk" and "misuse" are mostly pejorative terms here,
> since some people want exactly this behaviour, though I agree
> that some other people don't.
>
> > Administrators often block abusive messages using lists
> of sources
> > with a history of sending abusive messages. Within
> email, the client
> > IP address or verified host-name could be used to fairly identify
> > sources. Assuming a mechanism will deal with abusive
> replays, even
> > the DKIM signature could be fairly used.
> > Alas, an administrator may also consider acceptance granted by an
> > email-address authorization as verification of this as a source
> > identifier. This strategy has the effect of holding the email-
> > address domain owner culpable for authorizations that permit
> > acceptance of abusive messages. When the authorization is open-
> > ended, the email-address domain owner is therefore
> exposed to unfair
> > accruals of abuse based upon authorization.
>
> Restated: "If a domain owner publishes an open policy, and if
> some "bad" unsigned messages apparently emanate from that
> domain then the domain owner's reputation may suffer." I
> think that that's true, but of course its already true today
> without DKIM or SSP.
>
> > 3.2 Disruption caused by "closed" authorizations
> >
> > When closed authorizations are used, mediators or users obtaining
> > access from other providers will likely be outside the set of
> > identifiers contained within the authorization. Closed
> > authorizations will therefore disrupt common practices such as
> > posting to list servers, use of e-invites, and other similar
> > services.
>
> s/authorizations/policies/ and s/disruption/consequences/ and
> I'd agree. I'd also probably agree if someone said that the
> domains who'll operate closed policies won't care since that
> is just what they want for those domains.
>
> Restated: "Closed policies can disrupt practices such as
> posting to list servers, use of e-invites, and other similar
> services."
>
> > 3.3 Accommodating "closed" policies at the mediator
> >
> > When the mediator is a list server, one technique to
> ensure delivery
> > may be to modify the header being checked to reference a
> different
> > authorization record. One form of this technique may introduce
> > multiple From email-addresses where the first address
> conforms to the
> > identity of the list-server. A similar technique could
> be used to
> > overcome closed authorizations imposed by providers
> where the user
> > may also utilize two From addresses. This could be
> needed when the
> > second address is recognizable to the recipient, but otherwise
> > prohibited by closed authorization.
>
> I don't see the need to encourage >1 From here. Is this just
> you finding fault with ssp or are you really saying that this
> is what should be done? Anyway, >1 From is already mentioned
> in the threats draft.
>
> > 3.4 Increased overhead checking multiple From addresses
> >
> > The From header within a message may contain any number
> of addresses.
> > Some consider use of multiple addresses a valid means to overcome
> > limitations of an authorization mechanism.
> Alternatively, some wish
> > to check authorizations for every From address to preclude this
> > strategy being used to overcome the limitations imposed by
> > authorizations. Multiple From addresses could be
> confusing for the
> > recipient and poorly handled by the email applications.
> Precluding
> > acceptance of any From address that would be in conflict with the
> > specific email-address authorization further increases
> the overhead
> > associated with searching for authorizations.
>
> So don't do it! If your 3.3 didn't make it into the I-D then
> I guess this wouldn't either since its contingent.
>
> > 3.5 Coercive ratings when not publishing an authorization record
> >
> > Email-address authorization provides advantages for
> large domains.
> > Large domains are much less sensitive to abuse histories
> as they are
> > often excluded from block-lists due to their size.
> However, smaller
> > domains are much more prone to being negatively impacted
> by unfair
> > accruals.
> >
> > Down-rating domains without email-address authorization by larger
> > domains is a technique used to coerce other domains into
> publishing
> > authorizations. Open-ended authorizations are needed to permit
> > current practices expected by customers, but then these
> > authorizations may fall prey to bad actors who will utilize these
> > authorizations for their abuse. When these smaller
> domains become
> > placed within block-lists, there will be an exodus over
> to the larger
> > domains. Coercing the use of the email-address
> authorization also
> > mitigates the overhead associated with searching for
> these records.
>
> Everything there that I understood was already implied in 3.1
> above (that's after I applied the s/pejorative// filter:-)
>
> > 3.6 Exploitation of "open-ended" authorization being unfairly
> > attributed to the mail-address domain owner
> >
> > When messages obtain improved ratings which depend upon
> the email-
> > address having been authorized, then open-ended
> authorization records
> > will allow bad actor to use these authorization records
> to improve
> > upon their message acceptance ratings. To ensure messages are
> > accepted after passing through other mediators, an open-ended
> > authorization is required of the email-address domain owner.
> > Unfortunately, the email-address domain owner is unable
> to control
> > whether their authorization is seen as a "weak" form of
> > authentication and subsequently used to accrue abuse from all
> > permitted sources. As a result of message ratings based upon
> > authorization, open-ended authorizations, and the assumption of
> > authorization being a "weak" identifier, the email-address domain
> > owner may find their domain subsequently block-listed.
>
> Restated: "If unsigned mail from domains with open policies
> is treated any better on the basis that the policy exists,
> then bad actors will search for open policies in order to
> select the value for a falsified From header." I think that
> that's true and points up that SSP will have to carefully say
> what not to do.
>
> > 3.7 Overhead of email-address authorization retrivial
> >
> > The overhead related to a defensive strategy should not
> increase the
> > burden of the recipient as opposed to that of the sender.
> > Unfortunately, walking up label trees searching for email-address
> > authorization records imposes a relatively high overhead. This
> > overhead is kept high as few lookups return an
> authorization record
> > and therefore the lack of a record will be retained only briefly
> > within the DNS cache.
>
> Restated: "Policy statement retrieval has a cost." But I
> guess I knew that so I wouldn't think its worth saying. If
> SSP ends up being too costly then it won't be used and will
> therefore do no harm.
>
> > 3.8 Label depth found in abusive email versus legitimate email
> >
> > Bad actors take advantage of an evolving structure of
> top, second,
> > third, and forth level domains. Often bad actors create
> a series of
> > random labels above some domain to make it difficult to
> filter, as
> > the significant level where the direct registration is
> made becomes
> > difficult to determine algorithmically. This practice tends to
> > increase the number of labels found in abusive messages.
>
> Restated: "Searching for a policy statement may have a
> significant cost and bad actors can select messages so as to
> maximise this cost in an attempt at DoS." Which if true means
> that SSP has to include anti-DoS at design time, which is a
> good statement to make.
>
> > 3.9 Dictionary attacks of local-part authorizations
> >
> > Defensive programs currently defend against dictionary
> attacks being
> > attempted at the SMTP server. DNS however is not
> normally designed
> > to identify such searches, and with the lower latency of
> DNS, these
> > searches can be more productive at determining valid
> email-addresses
> > when user specific authorizations are being published.
>
> There's already anothter thing which is called a dictionary
> attack so I wouldn't use the term.
>
> Restated: "Policy statements inherently expose information
> about the domain to which the policy is intended to apply.
> Bad actors can use this information to select values for
> inclusion in messages."
>
> So, if I collect together those restatements then my synopsis
> of your suggested text would be:
>
> "Policies can be open or closed. Open policies define a set of
> conformant messages and are silent about other messages. Closed
> policies define the set of conformant messages and other messages
> do not conform to the policy.
>
> If a domain owner publishes an open policy, and if some "bad"
> unsigned messages apparently emanate from that domain then the
> domain owner's reputation may suffer.
>
> Closed policies can disrupt practices such as posting to list
> servers, use of e-invites, and other similar services.
>
> If unsigned mail from domains with open policies is treated
> any better on the basis that the policy exists, then bad actors
> will search for open policies in order to select the value for a
> falsified From header.
>
> Searching for a policy statement may have a significant cost and
> bad actors can select messages so as to maximise this cost in
> an attempt at DoS.
>
> Policy statements inherently expose information about the domain
> to which the policy is intended to apply. Bad actors can use
> this information to select values for inclusion in messages."
>
> I think (not that confidently mind you) that those statements
> are correct, and if so, could imagine a wordsmithed version
> ending up in the threats draft. Be interested in what others think.
>
> Cheers,
> Stephen.
>
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
>
>
More information about the ietf-dkim
mailing list