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