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

Doug,

I've read your restatement of this but I'd still summarise it
in just the same way (again talking about policy rather than
affirmations). Since there's no point in doing that again, I'm
happy just see where the consensus ends up,

Stephen.

Douglas Otis wrote:
> On Jan 12, 2006, at 6:17 AM, Stephen Farrell wrote:
>
> > 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.
> I think I understand this perspective.  I will use terminology that 
> perhaps more accurately reflects the actual mechanism.  I have looked at 
> your restatements, but I feel much of the concern is being missed.  I 
> have attempted to remove some of the offensive terminology and then 
> emphasize what seems to have been overlooked.
>   The terms "open-ended" and "closed" affirmation:
>
>    A basic function of email-address affirmation referenced by way of
>    a derived identity is to influence the acceptance or rejection of
>    a message.  The term "closed" indicates acceptance is based upon a
>    concurrent 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
>    affirmation.  This definition is not altered by the rating of
>    messages once 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" affirmations
>
>   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 as a
>   result of an email-address affirmation as "verification of the
>   reference identity as a source identifier".  This strategy has the
>   effect of holding the email-address domain owner culpable for
>   affirmations that lead to acceptance of abusive messages.  When the
>   affirmation is open-ended, the email-address domain owner is
>   therefore exposed to unfair accruals of abuse based upon
>   affirmations.
>
> 3.2  Consequences of "closed" affirmations
>
>   When closed affirmations are used, mediators or users obtaining
>   access from other providers will likely be outside the set of
>   identifiers contained within the affirmation.  Closed affirmations
>   will therefore disrupt common practices, such as posting to list
>   servers, use of e-invites, and other similar services.
>
> 3.3  Impact of accommodating "closed" affirmations
>
>   As a result of affirmations being withheld, the use of multiple
>   email-addresses could be employed.  When the mediator is a list
>   server, one technique that could be used to ensure delivery would be
>   to modify the header being checked to reference a different
>   affirmation record.  One form of this technique may introduce
>   multiple From email-addresses, where the first email-address conforms
>   to the identity of the list-server.  A similar technique could be
>   used to overcome closed affirmations 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 affirmation.
>
> 3.4  Increased overhead checking multiple From addresses
>
>   The From header within a message may contain any number of addresses.
>   Some may consider multiple email-addresses a valid means to overcome
>   limitations imposed by an affirmation mechanism.  An email-address
>   affirmation strategy should either recommend the selection of the
>   first email-address or recommend all email-addresses be checked.  To
>   permit a method for conveying the purported author, affirmations
>   could be limited to the first email-address.  However, multiple From
>   addresses creates risks by confusing the recipient and may be poorly
>   handled by the email applications.  Precluding acceptance of any From
>   address in conflict with an affirmation further increases the
>   overhead associated with searching for affirmations.
>
> 3.5  Coercive ratings when not publishing an affirmation record
>
>   Email-address derived affirmations 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 affirmations by larger
>   domains is a technique used to coerce other domains into publishing
>   affirmations.  Open-ended affirmations are needed to permit current
>   practices expected by customers, but then these affirmations may fall
>   prey to bad actors who utilize them 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 affirmation also mitigates the overhead associated with
>   searching for these records.
>
>
> 3.6  Exploitation of "open-ended" affirmation being unfairly attributed
>      to the mail-address domain owner
>
>   When messages obtain improved ratings which depend upon the email-
>   address having been affirmed, then open-ended affirmation records
>   will allow bad actor to use these affirmation records to improve
>   their message acceptance ratings.  To ensure messages are accepted
>   after passing through other mediators, an open-ended affirmation is
>   required of the email-address domain owner.  Unfortunately, the
>   email-address domain owner is unable to control whether their
>   affirmation 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 affirmation, open-ended
>   affirmations, and the assumption of affirmation being a "weak"
>   identifier, the email-address domain owner may find their domain
>   subsequently block-listed.
>
> 3.7  Overhead of email-address affirmation 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
>   affirmation records imposes a relatively high overhead.  This
>   overhead is kept high as few lookups return an affirmation record and
>   therefore the lack of a record will be retained only briefly within
>   the DNS cache.  This increased overhead must be mitigated or this
>   will increase the susceptibility of being overwhelmed by abusive
>   messages.
>
> 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  Email-address guessing attacks of local-part affirmations
>
>   Defensive programs currently defend against email-address guessing
>   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 attacks can be more productive at determining
>   valid email-addresses when user specific affirmations are being
>   published.
>
>
>
> > 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.
> Open policies (open affirmations) affirm the use of the email-address by 
> indicating what signatures or lack of signatures are acceptable.  In the 
> case of an open affirmation, the use of any email-address is equally 
> affirmed.  The reference identifier is derived from the email-address 
> which is affirmed when the signature is within the set of concurrent 
> identifiers determined by the SSP record.  On the other hand, a closed 
> policy only affirms with specific signatures.  Assuming there is value 
> associated with the email-address domain matching the signing-domain, 
> this value would be independent of the affirmation derived from the 
> email-address.
> The value of the email-address domain matching that of the signing 
> domain depends upon the usage patterns.  If it becomes common for large 
> providers to sign any and all email-addresses, and for bad-actors to 
> sign their own messages, the value obtained when these domains match 
> would be hard to quantify.  This value would not be a function of the 
> affirmation record however.
>
> > 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.
> The email-address domain owner's reputation may unfairly suffer.  This 
> seems to have missed the problem.
>
> > Closed policies can disrupt practices such as posting to list servers, 
> > use of e-invites, and other similar services.
> This should be stated as _common_ practices in the impact statement.
>
>
> > 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.
> Perhaps signed or unsigned email from email-address domains with open 
> affirmations.  The open affirmation indicates what signatures are 
> acceptable.  SSP looks at the email-address and then decides if the 
> signature is acceptable as a means to affirm the use of the 
> email-address by the signer.
>
> > 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.
> This misses much of the concern.  The result of using more than normal 
> labels is independent of the desire to create a DoS.  In fact most bad 
> actors would want their email accepted, but employ a common strategy to 
> avoid being easily identified.  The DoS concern should be focused upon 
> the ability to extend current equipment to handle increased recipient 
> burdens.  DKIM requires the entire message be accepted before the 
> signature can be checked.  Checking will require the lookup of a public 
> key that hopefully will be cached.  This caching may not be practical 
> when per-user keys are used.  SSP however adds searches which comprise a 
> sequence of rather expensive lookups, as most will return no-record not 
> likely be cached.  Of course the per-user aspect of caching pertains to 
> the affirmation records as well.  This overhead could be exasperated by 
> demanding all From email-addresses should be checked.
>
> > 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."
> The exposure of email-addresses is impacted by the use of 'g=' within 
> the key, the 'i=' within the signature, and the 'o=^' in the SSP 
> record.  There is active and illicit trading of email-addresses which 
> are used for the targets of abusive messages.  It seems rather ironic 
> that an effort to abate abuse adds new ways to expose more targets for 
> abuse.
> -Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org