ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] NEW ISSUE: SSP-02: Policy Scope

2008-02-15 12:33:01

On Feb 15, 2008, at 4:50 AM, Charles Lindsey wrote:

On Thu, 14 Feb 2008 19:08:41 -0000, Douglas Otis <dotis(_at_)mail- abuse.org> wrote:

On Feb 14, 2008, at 3:26 AM, Charles Lindsey wrote:
If you want to indicate that information, then propose a new tag within the SSP record for the purpose. But the default should be that the SSP applies to all modes of transport. Otherwise the Bad Guys will just send mail like the following:

Received: by bar.com from foo.com by SMTP ...
Received: by foo.com from ebay.com by UUCP ...
From: security(_at_)ebay(_dot_)com
[NO DKIM signature]

Agreed. This issue does not appear to have been entered into the RT tracking, but both you and Jim have suggested this alternative solution. Here is a more formalized suggestion for a tag added to the policy record.

s= Policy Scope (plain-text; OPTIONAL; default is "SMTP").  A colon-

No! The default must be '*'.

The concern regarding defaults was addressed in Take #3. This version includes a means to exclude policy.

   *  matches against all unlisted transport protocols
   !  disavows protocol use
   -  excludes protocol from policy assertions

I suspect the default should be "s=SMTP" where this would be the same as "s=SMTP:-*". When the domain exchanges no communication whatsoever, "s=!*" could be used. When only SMTP messages are used, then "s=SMTP:!*" would make this assertion.

But you have to make it clear that verifiers can only discern the protocol used by the originating site by carefull examination of Received headers (and believable ones at that). So I am still very dubious about adding this feature.


Trace headers can not be included within DKIM signatures. This limitation means DKIM policy applied against messages arriving over SMTP may affect messages passing though third-party protocol gateways bridging other protocols into SMTP. When messages arrive over different protocols within the same administrative domain, Authentication-Results headers could be used to indicate which protocol transmitted the message into the administrative domain, where these messages are placed into a common mailbox. It would be wrong to assume this is always the case.

See:
http://www3.tools.ietf.org/html/draft-kucherawy-sender-auth-header-11

The significant value in the Authentication-Results header is that it can be filtered at border MTAs. By adding a ptype of "Transport=<protocol>" to this header, a gateway can thereby indicate which transport protocol introduced the message. Unless this information is conveyed to the recipient by some mechanism when the mailbox normally serves as a repository SMTP messages, it would be better to apply policy that pertains to SMTP. This may mean a DKIM policy of "all" may cause some third-party gateway related messages to be refused or placed within a different folder as a result.

A policy scope mechanism allows other transports to apply policy in accordance with the domains assertion of protocol support, and whether the DKIM specific assertion should be applied. As such, an a DKIM/ SMTP policy of "all" would not affect messages sent over NNTP with a policy scope of "s=SMTP" for example. As other forms of message exchange implement DKIM, the scope of DKIM specific policies assertions becomes more critical. When the NTTP message is translated into message carried by SMTP, then SMTP policy may negatively affect the categorization of the NNTP message when these are not being signed.

This WG is largely comprised of those primarily focused upon SMTP. As such, DKIM policy is being considered only from the aspect of SMTP. While DKIM could be implemented by other types x822 message exchange, few would expect all of these communications to simultaneously implement DKIM. There are a few choices to resolve this potential issue.

a) Stipulate the *SP policy record applies to messages arriving over SMTP (require different policy domain labels for each protocol).

b) Provide a scope parameter within the policy record.

From a maintenance and overhead standpoint, option "b" could be the best solution. In Take #3, to make this friendly to gateways change:

When a protocol has been disavowed, any further DKIM related transactions should cease.

with:

When all protocols has been disavowed, any further DKIM related transactions should cease.

This last statement provides a means to protect specific domains and their parent domain from an inordinate amount of DNS traffic when an existing domain is spoofed in a spam campaign. The policy scope parameter allows other types of message spoofing to be mitigated with as DKIM becomes implemented for each respective transport. The fact that a protocol can be bridged into SMTP should not inhibit the use of "all" for SMTP, or for other protocols to assume that "all" only applies to SMTP. For DKIM to offer it greatest protections, a means to scope the policy is essential. Pick "a" or "b".

-Doug




_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>