Subject: [ietf-dkim] ssp req 02 available

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Oct 2006 07:40:41 -0700

until they hit the repository...

http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-02.html
http://mtcc.com/standards/draft-ietf-dkim-ssp-requirements-02.txt

       Mike, I'll try to come up with a summary in a bit...
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Oct 2006 15:51:46 +0100

Good job. Thanks for getting this in before the deadline,
S.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Oct 2006 15:20:33 -0700

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-masked]" is signed by "benefits.example.com",  
semantics to indicate the email-address is assured valid are lost.   
In addition, "[email-masked]" 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-masked]" 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.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Oct 2006 15:27:18 -0700

On Oct 20, 2006, at 3:20 PM, Douglas Otis wrote:

Correction:

SPF incurs a high overhead and offers an extremely dangerous means  
for making these associations.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Oct 2006 03:12:05 +0200

Douglas Otis wrote:

> Ten or eleven SPF records can be chained, where each set may contain
> 10 mechanisms

10 chained records => 10 "include" or "redirect" => limit of 10 reached.
The next contained mechanism - anything more elaborated than an "ip4",
"ip6", or "all" - results in a PermError.

> each mechanism may then invoke up to 10 additional DNS transactions

The two mechanisms doing that are "ptr" and "mx", and "ptr" depends on
the IP of the SMTP client.  That leaves "mx" as the only mechanism for
this consideration.

> Each name resolved using SPF may target a victim not seen anywhere
> within the message with 100 DNS transactions.

The attacker can construct a policy with 10 "mx" mechanisms, with 10
fabricated names per MX in the attacked domain.  The attacker won't
send the IPs of those names in the q=mx reply by his name server, so
that results in 100 queries to the name server of the attacked domain.

After that the SMTP server in question has these 100 answers cached.

Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 22 Oct 2006 12:10:49 -0700

> "ip6", or "all" - results in a PermError.

Many SPF RRs have wildcard labels. A series of 10 subsequent SPF RR
transactions with random sub-domains (enabled with SPF local-part
macros) will never be found in DNS cache.  Multiply this sequence by
each message name being resolved, multiply again for each instance
within the message path where an SPF check is made (MTAs & MUAs), and
multiply again for each recipient receiving the message.  These
transactions can be destructive by targeting DNS while not producing an
error.

The initial SPF RR can also point to any large TXT records causing
fragmentation in a manner similar to the EDNS0 exploit.  Terminate the
initial SPF RR with "+all" as does Bell Canada, and the attack provides
a "PASS" without wasting a mechanism.  Invoking an error may actually
cause another SPF RR transaction to occur. 

> the IP of the SMTP client.  That leaves "mx" as the only mechanism for

This is making assumptions about the nature of an attack.  However, a
redirected attack is likely to utilize the SPF MX mechanism for the
greatest gain and flexibility.

> After that the SMTP server in question has these 100 answers cached.

Review the attack outlined in the draft.  About 70% of spam is from
compromised systems, often sent in concert at a low rate.  Resolving a
name with SPF may invoke more than 100 targeted DNS transactions.  Some
SPF libraries take shortcuts and do not limit subsequent MX address
resolutions or even the number of mechanisms, using recursion limits and
time-outs instead.  To ascertain the impact, the overhead must be
multiplied by each name being resolved, multiplied again by each
instance within the message's path where an SPF check is made, and
multiplied again by the number of recipients.

A query made for 100 non-existent address records still provides 64:1
amplification for one name, one instance, and one recipient.  (There are
techniques to increase this gain, but not covered by the draft.)  This
gain is multiplied by the number of names, instances, and recipients.
The amplification of this exploit can exceed 1000:1 and even 10,000:1,
where including DKIM names substantially increases risks, as there is no
limit on the number of DKIM signatures per message.

With extremely high amplification and a likelihood that message sources
are measured in the tens of thousands, the rate of messages being sent
by each source can be extremely low and virtually impossible to detect.
The victim will not be evident in any SMTP log.  Each message can use
different and unrelated originating domains, and still target the same
victim.  Repeating a query for the same non-existent address only needs
to be delayed by the duration of negative caching.

The high amplification and low send rates means this negative caching
delay for a sustained attack may permit recycling (repeating the
local-part used by the trigger message) after a set of a dozen messages.
When done in concert, spam is still sent without affecting its delivery.
Although not apparent at the source, the resulting attack may still
taking down backbone connections, disable any number of DNS servers, and
poison any number of DNS resolvers.  Efforts directed toward BCP38 and
ACLs for recursive DNS resolvers offer no protection from this threat.

-Doug