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

[Stephen Farrell]

Hi Doug,

Thanks for making the effort - I do appreciate it & will
post a substantive response later on today (gotta go
inflict myself on some unfortunate students in the
meantime:-)

Cheers,
S.

Douglas Otis wrote:
> 
> On Jan 9, 2006, at 12:02 PM, Stephen Farrell wrote:
> 
>>
>> I'd love to see you write that text up that could be used in the
>> threats draft. I've yet to see it in a usable form.
> 
> 
> 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.
> 
>    SSP 'o=' Qualifiers:
>          "~" Signs some (open)
>          "-" All signed & allow other signatures. (open)
>          "!" All signed. (closed)
>          "." Never sends mail. (closed)
>          "^" Check user specific policy (deferred)
> 
> 
> 3.  SSP Related Threats
> 
> 3.1  Risks associated with the misuse of "open-ended" authorizations
> 
>    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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> -Doug
> 
> 
>