-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)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