Subject: [ietf-dkim] RFC 4871 on DomainKeys Identified Mail (DKIM) Signatures (fwd)

From: John Levine <[email-masked]>
Date: 23 May 2007 02:53:29 -0000

The DKIM RFC is finally out.  Here's the message posted to ietf-announce.

R's,
John

From: [email-masked]
Subject: RFC 4871 on DomainKeys Identified Mail (DKIM) Signatures
Date: Wed, 23 May 2007 01:58:00 +0000 (UTC)
Message-ID: <[email-masked]>

A new Request for Comments is now available in online RFC libraries.

        RFC 4871

        Title:      DomainKeys Identified Mail (DKIM) Signatures 
        Author:     E. Allman, J. Callas,
                    M. Delany, M. Libbey,
                    J. Fenton, M. Thomas
        Status:     Standards Track
        Date:       May 2007
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],  
                    [email-masked], 
                    [email-masked],  [email-masked]
        Pages:      71
        Characters: 166054
        Obsoletes:  RFC4870
        See-Also:   

        I-D Tag:    draft-ietf-dkim-base-10.txt

        URL:        http://www.rfc-editor.org/rfc/rfc4871.txt

DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email using public-key cryptography and
key server technology to permit verification of the source and
contents of messages by either Mail Transfer Agents (MTAs) or Mail
User Agents (MUAs).  The ultimate goal of this framework is to permit
a signing domain to assert responsibility for a message, thus
protecting message signer identity and the integrity of the messages
they convey while retaining the functionality of Internet email as it
is known today.  Protection of email identity may assist in the
global control of "spam" and "phishing".  [STANDARDS TRACK]

This document is a product of the Domain Keys Identified Mail
Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and 
suggestions for improvements.Please refer to the current edition of the 
Internet Official Protocol Standards (STD 1) for the standardization 
state and status of this protocol.  Distribution of this memo is 
unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 May 2007 16:07:16 +0100

Well congrats and well done to us all!

Now we need to get SSP done.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 May 2007 11:15:13 -0700

> Now we need to get SSP done.

An area not well addresses by the current SSP requirement is however  
extremely important to the typical high volume email sender-

Ensuring the SMTP client obtains a reputation based upon a DKIM domain.

While DKIM signatures assure content, these signatures in many cases  
will be unable to convey an assurance the SMTP client is associated  
with the DKIM domain.  In such cases, replay abuse may inhibit  
reliance upon the DKIM signature as a basis of acceptance.

Unless the industry adopts a convention where SMTP clients ensure  
host-names are within the DKIM signature domain, providing an  
alternative scheme for this association may prove extremely helpful.

There should be grave concerns with respect to utilizing SPF as a  
means for providing this function.  The local-macro expansion feature  
of this script-like scheme enables a _resource-free_ means to stage a  
DoS attack while spamming!  The many operations required to acquire  
SPF record sets also makes this approach extremely dangerous in  
general, as this can lead to _very_ high amplifications.  Dissuading  
use of dangerous existing libraries acquiring SPF records may  
actually require use of +all, where only CIDR constructs are used for  
white-listing purposes.

SSP can provide a much safer and lower overhead alternative for  
associating signatures with the SMTP client.  The DKIM signing domain  
would only need to publish a record with a hashed prefix of  
authorized SMTP clients.  These records at such locations ensure the  
DKIM signature is not being replayed abusively.  This would permit a  
simple means to convey the reputation of the DKIM signature upon the  
SMTP client and related IP address.

This can be done by using a convention hashing only upper labels of  
the SMTP client host-name as a basis for this authorization.  This  
would then permit any host-name within this domain to be associated  
with the DKIM signature.  This would involve a _single_ query where  
either the SMTP client is associated using this technique, or not.   
This would then permit more stringent policies which may wish to  
differentiate those SMTP clients not associated with the DKIM  
signature either directly or indirectly using such an authorization  
scheme.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 May 2007 08:06:01 +0100

Hi Doug,

We've had last call on the requirements document. You seem to
me to be repeating a request that wasn't accepted, but I've
yet to track back the issue tracker to check that. I hope I
don't need to.

Our next step with the SSP requirements document is to push
it to the IESG (on Barry's to-do list I believe).

Stephen.

Douglas Otis wrote:
> will be unable to convey an assurance the SMTP client is associated with 
> the DKIM domain.  In such cases, replay abuse may inhibit reliance upon 
> the DKIM signature as a basis of acceptance.
> 
> There should be grave concerns with respect to utilizing SPF as a means 
> for providing this function.  The local-macro expansion feature of this 
> script-like scheme enables a _resource-free_ means to stage a DoS attack 
> while spamming!  The many operations required to acquire SPF record sets 
> also makes this approach extremely dangerous in general, as this can 
> lead to _very_ high amplifications.  Dissuading use of dangerous 
> existing libraries acquiring SPF records may actually require use of 
> +all, where only CIDR constructs are used for white-listing purposes.
> 
> would only need to publish a record with a hashed prefix of authorized 
> SMTP clients.  These records at such locations ensure the DKIM signature 
> is not being replayed abusively.  This would permit a simple means to 
> convey the reputation of the DKIM signature upon the SMTP client and 
> related IP address.
> 
> This can be done by using a convention hashing only upper labels of the 
> SMTP client host-name as a basis for this authorization.  This would 
> then permit any host-name within this domain to be associated with the 
> DKIM signature.  This would involve a _single_ query where either the 
> SMTP client is associated using this technique, or not.  This would then 
> permit more stringent policies which may wish to differentiate those 
> SMTP clients not associated with the DKIM signature either directly or 
> indirectly using such an authorization scheme.
> 
> -Doug
>

---

From: Damon <[email-masked]>
Date: Thu, 24 May 2007 09:39:11 -0400

> Now we need to get SSP done.

+1 :-)

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 May 2007 11:03:26 -0700

On May 24, 2007, at 12:06 AM, Stephen Farrell wrote:

> We've had last call on the requirements document. You seem to me to  
> be repeating a request that wasn't accepted, but I've yet to track  
> back the issue tracker to check that. I hope I don't need to.
>
> Our next step with the SSP requirements document is to push it to  
> the IESG (on Barry's to-do list I believe).

There is a clear desire to use DKIM in conjunction with some type of  
domain based reputation service.  However, DKIM has _not_ resolved  
how replay abuse is to be handled.  This becomes a security concern  
when someone then suggests SPF is to be the means to associate domains.

Because DKIM has not resolved the issue of replay abuse, DKIM is  
indirectly promoting a dangerous means to associate domains.  The  
DKIM WG should reconsider their strategy.

When a DKIM signature does not match the domain of an email-address,  
the email-address is not assured.  This should be okay.

When the EHLO does not match the DKIM domain, the recipient is at  
risk of replay abuse when basing acceptance upon the DKIM domain.   
Hence, when the DKIM domain does not match the EHLO domain, DKIM's  
reputation MUST not apply.  For many, this is _not_ okay.

---

One solution might be to negotiate the necessary elements for  
permitting email providers to identify SMTP clients as being within  
the signer's DKIM domain.  However, most customers of an email  
service provider will not be comfortable making such arrangements.

Another solution might be to publish a _single_ small record that  
associates the EHLO domain with that of the DKIM domain.  Such  
associations would represent a type of authorization and indication  
of trust.  Such a scheme would not place either the email service  
provider or their customer in jeopardy in being erroneously  
identified for something beyond their control.  The same record could  
also indicate signing policy.  This can be accomplished within one  
and perhaps two DNS transactions _at the most_.  It is _very_  
important that the DKIM WG carefully consider the overhead  
surrounding use of DKIM.

---

Some have rather wantonly dismissed concerns related to DNS records  
able to cause a flurry of subsequent queries to _uninvolved_ domains  
based upon various email-address's local-parts.  Such records are  
cached and can be reused _any_ number of times within a spam run  
where these local-parts _will_ likely change.  Some have wantonly  
dismissed concerns related to DNS transactions demanded by a strategy  
attempting to resolve _all_ IP addresses used by as many as _10_  
different domains _all at once_.  The level of DDoS amplification  
this might involve is simply astounding!

The DKIM WG should carefully reconsider this issue for security  
reasons alone.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Fri, 25 May 2007 20:15:08 -0400

> it to the IESG (on Barry's to-do list I believe).

Yep, and that's now done.

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])

---

From: Barry Leiba <[email-masked]>
Date: Fri, 25 May 2007 20:18:37 -0400

> indirectly promoting a dangerous means to associate domains.  The DKIM 
> WG should reconsider their strategy.

Doug, will you (briefly) say what the replay scenario you're looking to 
address is?  Thanks.

Barry

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 May 2007 15:02:14 -0700

On May 25, 2007, at 5:18 PM, Barry Leiba wrote:

> Doug, will you (briefly) say what the replay scenario you're  
> looking to address is?  Thanks.

A DKIM signed message can be replayed from other SMTP clients.  This  
is a desirable feature, but permits abuse when receivers base message  
acceptance upon (the reputation of) the DKIM domain.

Replay abuse has been defined, and should be understood.  The concern  
is for those who will be affected by replay abuse mitigation strategies.

Mitigation would condition DKIM domain consideration to those  
messages where:

  A) the SMTP RCPT TO is within the signed portion of the message,

  B) or when the SMTP client is within the DKIM domain.

For a typical bulk sender, these conditions are not problematic.   
However, these conditions are problematic for many valid use  
scenarios.  These mitigation conditions have a potential to greatly  
lessen email delivery integrity.  This problem grows as DKIM domains  
become a greater component of acceptance.  The DKIM WG should  
consider how SSP records might safely extend use scenarios where a  
valid DKIM signature can remain a basis for acceptance.

Ideally, the extension information would be contained directly within  
the message to extend the mitigation A strategy.  Unfortunately BCC  
seems to preclude such direct methods, but there might be a means  
that combines some existing SMTP parameter with a cryptographic hash  
function.  Another method would be to extend the mitigation B  
strategy by indicating which SMTP clients are considered  
trustworthy.  A mitigation B strategy is not safely fulfilled by SPF,  
so it is imperative that a safe means be provided when only the  
mitigation B strategy remains available.

-Doug

"Good ideas and innovations must be driven into existence by  
courageous patience."  Hyman Rickover

---

From: Barry Leiba <[email-masked]>
Date: Sat, 26 May 2007 18:29:53 -0400

> A DKIM signed message can be replayed from other SMTP clients.  This is 
> a desirable feature, but permits abuse when receivers base message 

Are you talking about the scenario wherein you send a message in a 
legitimate way and capture the signed message (for instance, you send a 
message from your mail-abuse.org address to your own yahoo.com address), 
and then you re-send that message, perhaps as spam, from some other 
domain (say, spam-is-profitable.com)?

Barry

--
Barry Leiba, DKIM working group chair  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Douglas Otis <[email-masked]>
Date: Sat, 26 May 2007 16:40:50 -0700

On May 26, 2007, at 3:29 PM, Barry Leiba wrote:

>> A DKIM signed message can be replayed from other SMTP clients.   
>> This is a desirable feature, but permits abuse when receivers base  
>> message acceptance upon (the reputation of) the DKIM domain.
>
> legitimate way and capture the signed message (for instance, you  
> send a message from your mail-abuse.org address to your own  
> yahoo.com address), and then you re-send that message, perhaps as  
> spam, from some other domain (say, spam-is-profitable.com)?

Your example complicates this, as Yahoo adds a signature, whereas the  
domain used to send this message does not.

Any message has a potential of becoming spam.  Who initiated a  
message to a recipient is important in assessment of:

  a) reputation, and

  b) message acceptance.

Without mitigating conditions, messages signed by yahoo.com will not  
safely serve as a basis for either reputation or acceptance.

Perhaps a more likely scenario would be where a bad-actor sends a  
message from a DKIM signing domain comprising a large number of users  
to some other domain also comprising a large number of users.  These  
messages might then be reissued from a bot-net within the signing  
domain.  Soon we'll complete an ongoing process categorizing email  
sources, but of about 70 million active email sources, more than half  
behave like a bot-net.

Mitigation might need to be better defined:

  B) or when a _confirmed_ SMTP client is within the DKIM domain.

-Doug

---

From: SM <[email-masked]>
Date: Sat, 26 May 2007 20:49:25 -0700

>  B) or when a _confirmed_ SMTP client is within the DKIM domain.

Both A and B would affect DKIM verification if the message goes 
through a mailing list or a forwarder.

DKIM operates entirely on the content of the message (RFC 4686 
Section 1.1).  Your requirement goes against that.  Maybe you could 
use "revocation identifiers" as described in the Chosen Message 
Replay scenario.

Regards,
-sm

---

From: Hector Santos <[email-masked]>
Date: Sun, 27 May 2007 00:37:09 -0400

SM wrote:
> Both A and B would affect DKIM verification if the message goes through 
> a mailing list or a forwarder.
> 
> DKIM operates entirely on the content of the message (RFC 4686 Section 
> 1.1).  Your requirement goes against that.  Maybe you could use 
> "revocation identifiers" as described in the Chosen Message Replay 
> scenario.
> 

I don't think we should lose focus of the POLICY expectations of DKIM or 
more specifically SSP.

Right now, even with the great knowledge DKIM is now an official RFC 
standard, I still have no real incentive to implement it (turn it on), 
making it a stock feature of our product and thus open a DKIM-BASE only 
environment "Pandora's Box" of issues with my customers.

In my view, once SSP is itself a IETF standard, many things will come 
together, including SMTP level considerations and in my view, from an 
industry  competitive cooperation standpoint, each will have their own 
set of solutions that might include DKIM/SSP among other things.  But I 
think we will be losing focus to make the tie-in to SMTP without SSP 
being finished.

My take on it.

Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 May 2007 09:24:39 -0700

> use "revocation identifiers" as described in the Chosen Message  

Neither suggested replay abuse mitigation strategy affects  
verification of the DKIM signature, nor has the WG addressed this  
concern.

Many hope to base reputation upon the DKIM domain.  However DKIM  
domain reputation will impact delivery for many more messages than  
just those being forwarded.

As example, the DOSP draft indicates signing policy and can mitigate  
replay abuse to accommodate forwarding sources, mailing-lists, and  
BCC messages.  Importantly, any such similar scheme eliminates  
dangers associated with SPF as currently the only other alternative!

Otherwise, the DKIM WG must make a very strong statement DKIM is only  
suitable for emails addressed specifically to the recipient due to  
replay abuse mitigation concerns.

-Doug

---

From: SM <[email-masked]>
Date: Sun, 27 May 2007 11:06:49 -0700

Hi Doug,
>dangers associated with SPF as currently the only other alternative!

I read your draft.  I didn't see any section that indicates how it 
can mitigate replay abuse to accommodate mailing lists and forwarders.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 May 2007 12:28:41 -0700

> can mitigate replay abuse to accommodate mailing lists and forwarders.

Associating SMTP clients with the DKIM Domain provides a means to  
extend replay abuse mitigation strategies and accommodate a greater  
range of usage scenarios.  This extension is able to cover cases  
where the SMTP RCPT TO is not contained with the message.  This  
situation likely occurs with BCC, mailing-lists, and forwarded  
messages.  Granted, forwarding domains must be specifically listed,  
whereas this scheme accommodates thousands without imposing  
additional lookups.

The scheme proposed by DOSP could be revised to exclude the left-most  
domain label in the hash to establish a type of shorthand.  To limit  
which hosts associate as an SMTP client, SMTP clients must then be  
assigned a specific sub-domain.

For those domains where some hosts are not trusted, SMTP clients  
would be placed within a sub-domain, for example 'mxo'.

  host1.mxo.large-isp.com
  host2.mxo.large-isp.com
...

  The DOSP records could then include just the hash of 'mxo.large- 
isp.com'.

-Doug

---

From: SM <[email-masked]>
Date: Sun, 27 May 2007 13:01:18 -0700

>whereas this scheme accommodates thousands without imposing

We don't know through which forwarders the mail will go through 
before reaching its final destination.  This message, for example, 
could have gone through a forwarder to reach my mailbox.

>would be placed within a sub-domain, for example 'mxo'.

How does that prevent replay abuse?  If some hosts are not trusted, 
mail from them should not be DKIM-signed.

Can you provide a specific example where DKIM signed mail from 
[email-masked] to me is protected from abuse?

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Sun, 27 May 2007 14:27:33 -0700

> could have gone through a forwarder to reach my mailbox.

As with any path registration scheme, paths must be known  
beforehand.  The DOSP scheme scales to accommodate _any_ number of  
paths.

Administrators could ask users to volunteer this information, or  
administrators could establish a forwarding service as a last leg of  
forwarded messages.  Those wanting this accommodation could be prone  
to a more spam when their account discovered, but the risk would only  
affect these users.

>> The scheme proposed by DOSP could be revised to exclude the left- 
>> most domain label in the hash to establish a type of shorthand.   
>> To limit which hosts associate as an SMTP client, SMTP clients  
>> must then be assigned a specific sub-domain.
>>

The concern is regarding replay abuse where messages are signed by  
trusted SMTP clients.  The recipients of these signed messages can  
not determine which SMTP clients the signer considers authorized  
(unless SPF were used).

> [email-masked] to me is protected from abuse?

This domain currently does not use DKIM, but assume that it did.   
Their DOSP records would indicate their authorized SMTP clients for  
originating SMTP MAIL FROM, and DKIM signatures.  These records could  
be checked for messages not specifically addressed the SMTP RCPT TO.

A message that is BCC to you can still be confirmed as authorized  
when received from an DOSP SMTP client.  Unless bad-actors have  
specific knowledge of provisions accommodating forwarded messages, or  
access to the authorized SMTP clients, they would have no ability to  
avoid mitigations in place preventing abusive replay.

The concept is rather simple.  The bad-actor is a normal user of mail- 
abuse.org and sends themselves messages to other accounts.  Mail- 
abuse.org rate limits accounts and promptly disables accounts  
reported and confirmed as abusive.

When DKIM serves as a basis for acceptance, without replay abuse  
mitigation, the bad-actor is still able to continue sending these  
messages to anyone and everyone until signatures expire.  They may  
have hundreds of such messages.  If mail-abuse.org grants public  
access to their service, the bad-actor could re-enroll and continue  
this behavior non-stop.  Replay abuse mitigation will become  
essential and prove disruptive to a large category of legitimate  
email use scenarios.  The DKIM WG should consider specific mitigation  
strategies that can apply for these legitimate use scenarios or  
insist that DKIM must never be used as a basis for acceptance.

DKIM will still reduce false-positive detection of phishing  
attempts.  Such filtering is not limited to specific email-addresses  
where reducing false positives is highly desirable.  This use tends  
to limit the scenarios suitable for DKIM.  It seems many desire that  
the DKIM domain be used as a basis for reputation, and there lies the  
problem.

-Doug

---

From: SM <[email-masked]>
Date: Tue, 29 May 2007 11:44:59 -0700

Hi Doug,
>beforehand.  The DOSP scheme scales to accommodate _any_ number of

That would be like SPF.

>to a more spam when their account discovered, but the risk would only

It's an administrative burden.  We can always tell which path a mail may take.

>The concept is rather simple.  The bad-actor is a normal user of 
>mail- abuse.org and sends themselves messages to other 
>accounts.  Mail- abuse.org rate limits accounts and promptly 
>disables accounts

You can have the same functionality with per-user keys without 
placing any restriction on forwarding.

>this behavior non-stop.  Replay abuse mitigation will become

Your proposal does not prevent the bad actor from re-enrolling.

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 May 2007 14:53:04 -0700

>> beforehand.  The DOSP scheme scales to accommodate _any_ number of  

SPF does not scale well and creates a significant DDoS concern.  Path  
registration is a PITA, however no other provisions are established  
for mitigating replay abuse.  This may cause messages not to be  
delivered when the RCPT TO can not be found within the message and  
when the SMTP client is not within the DKIM domain.  Opaque-ID  
records is another alternative, but this requires a response from the  
administrator.

>> administrators could establish a forwarding service as a last leg  
>> of forwarded messages.  Those wanting this accommodation could be  
>> prone to a more spam when their account discovered, but the risk  
>> would only affect these users.
>

You mean we can't always tell?  Yes, some notification to customers  
would need to be made.  An administrator could establish temporal  
mailboxes that act targets for forwarded messages, which then are  
delivered to their main mailbox.  This approach should be easy to  
administer and not overly expose customers to replay abuse.

>> mail-abuse.org and sends themselves messages to other accounts.   
>> Mail-abuse.org rate limits accounts and promptly disables accounts  

Per-user keys require the same level of administration as would  
Opaque-IDs, but per-user keys cause far more DNS traffic.  When email  
domains contain tens of millions of users, the amount of DNS traffic  
to support per-user keys is sizable and costly.

>> access to their service, the bad-actor could re-enroll and  
>> continue this behavior non-stop.  Replay abuse mitigation will become
>

Although we are working on a list to vet enrollment, public access  
remains problematic.  Replay abuse allows bad-actors to bypass normal  
rate and recipient limits that are normally in place.  Providing a  
safe means to authorize SMTP clients for either MAIL FROM or DKIM  
domains is a proactive means forestalling abuse.  The administrator  
would not need to be immediately reactive in disabling per-user  
keys.  With high loads on DNS caused by per-user keys, lookup  
failures may become common and cause DKIM to be ignored altogether. : (

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 29 May 2007 23:36:13 -0400

On Tuesday 29 May 2007 17:53, Douglas Otis wrote:

> SPF does not scale well and creates a significant DDoS concern.  

FWIW, the SPF project did a serious analysis of Doug's concerns and found that 
Doug's concerns are overblown with the processing limits in RFC 4408.  SPF 
does not present any unique DDoS concerns.  I realize this is OT for a DKIM 
list, but I'm getting tired of it.  I've sat back and said nothing about this 
nonsense for some time, but the DDoS concern is one that only Doug seems to 
have.  SPF has a number of arguments against it, but this isn't one of them.

http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis

Doug, this really isn't the forum to be discussing the merits of SPF. It 
attempts to solve a different problem than DKIM and that's probably enough 
for this list.

Scott K

---

From: SM <[email-masked]>
Date: Tue, 29 May 2007 21:05:50 -0700

>You mean we can't always tell?  Yes, some notification to customers

Yes, I meant "cannot". :-)

Regards,
-sm

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 May 2007 01:40:58 -0700

On May 29, 2007, at 8:36 PM, Scott Kitterman wrote:
> FWIW, the SPF project did a serious analysis of Doug's concerns and  
> found that Doug's concerns are overblown with the processing limits  
> in RFC 4408.  SPF does not present any unique DDoS concerns.  I  
> realize this is OT for a DKIM list, but I'm getting tired of it.   
> I've sat back and said nothing about this nonsense for some time,  
> but the DDoS concern is one that only Doug seems to have.  SPF has  
> a number of arguments against it, but this isn't one of them.
>

Analysis by the SPF project is not surprisingly biased.  It ignores  
several important aspects.  Problems related to NS record  
transactions are orthogonal to SPF, and can be addressed solely by  
affected DNS servers.  SPF is not within the realm controlled by DNS  
protocol, except by having DNS drop SPF records entirely.  It might  
come to that.

For example, their analysis ignores the impact of the SPF local-part  
macro capability.  How this mechanism might be utilized is  
demonstrated in the spf-dos exploit draft.  This "feature" provides a  
resource-free means for staging a DDoS attack in conjunction with  
_any_ typical spam run.  Many spam runs employ millions of SMTP  
clients.  Amplifications noted in the spf-dos exploit draft are  
generous to SPF, as these figures should not include spam traffic.   
When spam traffic is discounted as a given, the resulting  
amplifications better clarify benefits bad-actors obtain exploiting  
SPF.  Consumption of an attacker's resources are eliminated!  The  
same SPF cached record is able to induce an _infinite_ number of  
transactions against _any_ innocent domain, making such attacks  
directed anywhere virtually free.  No one is safe.  Perhaps the spf- 
dos draft needs to be updated.

The name-path draft was to illustrate that safe alternatives can be  
devised.  The name-path draft was not intended as a marketing ploy or  
self promotion, as their analysis suggests.  Am I making myself  
popular discussing this issue?

Statements that SPF only increases the number of existing  
transactions by 10 is wrong.  Libraries in accord with RFC4408 exceed  
100 new and directed transactions.  A vast number of poorly written  
libraries will not impose _any_ subsequent address resolution limits,  
a detail their analysis also ignores.  40+ pages in the spf-dos  
exploit draft represents a redacted trace of just _one_ call to an  
RFC 4408 compliant library resolving _one_ email-address.  The trace  
clearly illustrates a much greater number of transactions are  
generated.  Adding limits for the number of "no domain" responses  
would only make SPF more unreliable when so many records might  
legitimately be involved.  Early termination of the SPF script  
process defeats congestion avoidance, making SPF a serious threat  
indeed.  Even with tighter limits, an SPF DDoS attack remains free.   
Many spam runs are more than wide enough to cause considerable  
damage, even when fewer transactions are permitted.  Preventing or  
filtering the attack will be impossible.

> Doug, this really isn't the forum to be discussing the merits of  
> SPF. It attempts to solve a different problem than DKIM and that's  
> probably enough for this list.

Jim Fenton himself suggested SPF could be used in conjunction with  
DKIM to resolve possible replay problems.  Corporate marketing is  
busy promoting Sender-ID.  Whether it is DKIM or Sender-ID, SPF works  
like a script which must be "run" to obtain an answer.  As such, each  
additional domain MUST invoke a full set of SPF related transactions  
which only adds to the loathsome DDoS gains possible.

The DKIM WG is free to ignore likely problems caused by replay abuse  
caused by reputations based upon DKIM domains.  Problems likely to  
disrupt several valid email use scenarios.  Even per-user key with a  
TTL of zero is unlikely to dissuade abusive replays.  Abusive  
replays, even for a few hours, greatly exceeds volumes otherwise  
permitted by constraints normally in place.  And what level of DNS  
instability is acceptable?

Ending with a happy and on topic note, an authorization By-Name  
scheme, used in conjunction with DKIM, can also allow MAIL FROM  
addresses to be authorized.  This would provide a safe means to  
curtail a DKIM bounce with a "broken" signature exploit.  A message  
with an authorized MAIL FROM might even be more likely accepted on  
that basis alone, as it would not add to the backscatter problem when  
it gets bounced.  Much like Google increases the ranks of web pages  
referenced elsewhere, an authorization By-Name scheme provides a new  
type of reputation based upon those trusting the domain to handle  
their email.

-Doug