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