[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

[Stephen Farrell]

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.