On Oct 20, 2006, at 7:51 AM, Stephen Farrell wrote:
,----
|6.3. Practice and Expectation Requirements
|
|7. The Protocol MUST NOT invent a different means of allowing
| affiliated parties to sign on a domain's behalf. Because
| DKIM uses DNS to store selectors, there is always the
| ability for a domain holder to delegate all or parts of the
| _domainkey subdomain to an affiliated party of the domain
| holder's choosing. That is, the domain holder may be able to
| set a NS record for _domainkey.example.com to, say, an email
| provider who manages that namespace. There is also the
| ability for the domain holder to partition its namespace into
| subdomains to further constrain how third parties. For
| example, a domain holder could delegate only
| _domainkey.benefits.example.com to a third party to constrain
| the third party to only be able to produce valid signatures in
| the benefits.example.com subdomain. Last, a domain holder can
| even use CNAME's to delegate individual leaf nodes.
'____
When was this consensus reached? This is in conflict with several
participants and should be removed.
Serious problems can not be resolved with this imposed limitation.
Policy based domain designation:
- Ensures the domain responsible for signing the message remains
apparent and receives the desired feedback.
- Retains information that better affords protection for both the
transmitting entity and the affiliated email-address domain owner.
- Clarifies who maintains logs associated with the signing process
and eliminates the exchange of keys.
- Permits the email-address domain owner the discretion to indicate
which signing domains offer assured valid email-addresses.
- Does not necessitate any preceding administration and the prior
exchange of account specific details published by a second party
in DNS. (Lowers the TCO.)
- Incurs the same overhead as a CNAME by a different DNS.
- Does not reduce the integrity of DKIM signing as will
CNAME or DNS delegation.
- Never requires of use of your private keys by third-parties.
Some envision accountability being placed onto the email-address
domain owner is ideal, but an IP address assessment occurs early
within the SMTP session where there may not be an opportunity to even
assess DKIM signatures.
An inability to differentiate abusive replay means the IP address
must be retained to assess reputations. However, associating signing
domains with SMTP clients may allow abusive replay to be
differentiated. This could exclude abuse caused by competitors or
vandals, for example. Assessing the signing domain remains perilous
without associating the signing domain with the SMTP client. This
association is greatly simplified by a designation strategy.
Some have suggested the use of SPF as an association method. SPF
incurs a high overhead and does not offers an extremely dangerous
means for making these associations. SPF EHLO validation invokes the
same scripts used for MAILFROM or the PRA. Ten or eleven SPF records
can be chained, where each set may contain 10 mechanisms, each
mechanism may then invoke up to 10 additional DNS transactions (10 x
10 = 100). Each name resolved using SPF may target a victim not seen
anywhere within the message with 100 DNS transactions. When DKIM is
validated using SPF, this means each message may invoke three or more
separate evaluations, multiplied by the number of recipients, and
multiplied by the delivery stages where SPF evaluation occurs. The
gain of this attack can be extremely high > 70:1 even when only one
name is evaluated at one instance in the message's path. When 3
names are evaluated at 2 instances for 5 recipients, the
amplification can be > 2000:1. No ACLs or the implementation of BCP
38 provides any protection.
For an overview of the SPF threat see:
http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt
For an illustration of how policy can effectively designate different
domains see:
http://www.ietf.org/internet-drafts/draft-otis-dkim-dosp-02.txt
-Doug
P.S.
When "[EMAIL PROTECTED]" is signed by "benefits.example.com",
semantics to indicate the email-address is assured valid are lost.
In addition, "[EMAIL PROTECTED]" is not recognized by the base
draft as an affiliated email-address of the "benefits.example.com"
signature (not a first-party signature). Signing messages instead as
"[EMAIL PROTECTED]" is a practice that increases
successful spoofing. Retaining the same email-address then exposes
recipients to intra-domain spoofing where the ability to selectively
indicate which email-address is assured valid is lost. Child signing
also creates other vulnerabilities.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
