Subject: [ietf-dkim] bot-nets

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jun 2008 12:28:59 -0700

In the security considerations section, there were two paragraphs  
below DNS Attack added.  This was intended to be within a section  
called Bot-net Attack.

Why this section is important might be illustrated by with the  
following data.

A well respected email provider has a slight problem.  They send  
approximately ten billion emails a day, or about one hundred thousand  
each second from 2 million cached daily inquires from customers  
assumed to represent about 1/5000th of overall traffic.   It is clear  
that they understand there is a problem from their arrangement of  
outbound servers.  They have three tiers earning significantly  
different, but uniform ratings.  The first class tier sends little if  
any spam, the second class sends a small percentage of spam mixed  
together with about 2 billion messages, and the third class sends  
about 350 million a day with a high percentage being spam.  This  
provider publishes SPF records, and, in the past, asked why this space  
had not been white-listed.

It should not be difficult to understand the danger this provider's  
behaviour might represent.  As it would be for DKIM signatures and  
 From headers, the PRA is not restricted.  In the case of Sender-ID, a  
recipient of their message might be convinced to process perhaps nine  
macro expanded SPF records evaluating a PRA targeting some victim, and  
yet the message could still be authorized when the bad-actor finally  
includes the provider's highly respected SPF record.  What a concept!

I was prevented by several MAAWG members from making a presentation  
pointing out the dangers associated with Sender-ID then being touted  
by a new board member and soon highly promoted as an industry  
solution.  After all, this was a feature promised to enrich those  
supporting it.  There were even direct payments made to implementers.   
(The problem that SPF sans Sender-ID hoped to solve is more safely  
handled by adoption of RFC3834.  A reputation service could help make  
that happen.)

DKIM is intended to help solve the phishing problem.  IMHO, it can.   
However, the DKIM WG must not ignore DDoS issues.  It does not matter  
how many major email providers insist their mail does not represent a  
concern.  If ADSP were to limit how the i= parameter within the DKIM  
signature can be used, or insist that the "on-behalf-of" feature can  
be obtained by using multiple signatures, or by having the identity  
introduced through some undefined method, then clearly this WG has  
failed to appreciate the the danger as well.  Although admitting there  
is a problem may draw the interest regulators, where little good ever  
comes, by ensuring DKIM is able to help mitigate the bot-net issue, it  
can better head off the dangers associated with any eventual regulation.

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

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 27 Jun 2008 00:09:34 +0200

Douglas Otis wrote:
  
> This provider publishes SPF records

What a vague description, do they also publish WKS or MX
records ?  I trust that this has nothing to do with DKIM.

> the PRA is not restricted.

That could mean that they have no spf2.0/pra (or similar)
policy, or if they have it that there is no chance to get
a FAIL for any sending IP, or if there are FAILing cases,
that some IPs could result in NEUTRAL, for values of some
up to "almost all".

> a recipient of their message might be convinced to process
> perhaps nine macro expanded SPF records evaluating a PRA
> targeting some victim

A policy of an ordinary provider won't "target some victim".
A chain of nine "include:" or "redirect=" records eats up
nine of ten directives permitted to trigger additional DNS
queries.  

To get any "victim" in this scenario the policy has to use
nine "include:victim.example", which might be an attack or 
stupidity.  Because your description was about an ordinary
provider "attack" is out, so tell them how to get it right,
with a copy to [email-masked] 

> The problem that SPF sans Sender-ID hoped to solve is
> more safely handled by adoption of RFC3834.

Actually the problem tackled by RFC 4408, i.e. backscatter,
would defeat the core of 2821bis, RFC 3834, and RFC 5230,
where it is not solved.  As nothing else offers a general
solution - ignoring the obsolete reverse routes in STD 10 -
everybody is free to use a crystal ball or SPF to judge an
envelope return address, as the known precondition to make
2821bis and RFC 3834 work as designed.

And I'd wish that one of my providers would at least use a
crystal ball instead of accepting fake bounces allegedly
from [email-masked] with ZIPped worms =>
not all rubbish requires SPF, a minimal IQ can also help.

> A reputation service could help make that happen.

In that particular case I fear they'd end up with "it is
from me, I trust me", and continue to dump the worms in my
mailbox.  SpamCop always informs me that the open proxies
are known.  Stupidity is certainly a major factor wrt mail.

Folks could manage to decorate open proxies with a PASS :-(
But at least any bounces would then hit the stupid party.

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jun 2008 21:52:24 -0700

On Jun 26, 2008, at 3:09 PM, Frank Ellermann wrote:

> What a vague description, do they also publish WKS or MX records ?   
> I trust that this has nothing to do with DKIM.

The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.   
Although Sender-ID allows an override by version 2, it imposes the  
same risks, and is not used in this case.

The relevant concern is whether a bad actor can influence the PRA to  
take advantage of SPF macro expansion capabilities to source an attack  
using transactions expanded from cached SPF records.  Distributed  
attacks would be initiated by the evaluation of messages sent by  
exploited providers.  A bad actor's PRA/SPF record might link to an  
exploited provider's record or simply have the provider's CIDRs  
appended.  Not only can bad actors stage an attack using little of  
their own resources while also spamming, they also enjoy an enormous  
unblocked connection.  Of course, bad actors would also have their  
messages receive a Sender-ID and/or MAILFROM PASS authorization.  :^(

> That could mean that they have no spf2.0/pra (or similar) policy, or  
> if they have it that there is no chance to get a FAIL for any  
> sending IP, or if there are FAILing cases, that some IPs could  
> result in NEUTRAL, for values of some up to "almost all".

Version 2 records are not present.  A bad actor's messages can receive  
PRA PASS authorizations even within tightly constrained provider  
address lists.

>> a recipient of their message might be convinced to process perhaps  
>> nine macro expanded SPF records evaluating a PRA targeting some  
>> victim
>
> A policy of an ordinary provider won't "target some victim". A chain  
> of nine "include:" or "redirect=" records eats up nine of ten  
> directives permitted to trigger additional DNS queries.

A customer's message determines the PRA in various ways where macros,  
rather than DNS records directly, might do the bulk of the damage.   
Unfortunately, the situation could be worse for DKIM.

> To get any "victim" in this scenario the policy has to use nine  
> "include:victim.example", which might be an attack or stupidity.   
> Because your description was about an ordinary provider "attack" is  
> out, so tell them how to get it right, with a copy to [email-masked]

A bad-actor able to influence the PRA would be able to induce a series  
of transactions against a victim from a cached SPF macro expanded  
record.  Freedoms allowed in the construction of a message thereby  
become exploitable.  Freedoms are lost due to Sender-ID exploits.  The  
macro capability found in the SPF record can cause recipients to  
construct a set of transactions targeting a victim domain that is  
unrelated to any domain seen within the message.  For the bad actor,  
the additional cost to stage the attack is miniscule.

Although DKIM does not have a macro expanded records, the number of  
identities a bad actor could influence represents similar risks.  For  
this reason, those using DKIM may soon need to consider strategies to  
deal with this issue, depending upon who becomes the target of  
course.  The slight change to the definitions in the otis-dkim-adsp  
draft is aimed at ensuring a means to facilitate an anti bot-net  
effort without requiring additional signatures or identities.  A  
requirement for multiple signatures or identity structures would be  
heading in the wrong direction.  In addition, these changes make DKIM  
signatures generally more secure.  The concept behind the change is to  
permit a domain to always directly sign a message with an on-behalf-of  
identity that reflects either the author, or opaquely, an account.   
The TPA-ADSP extension allows a single transaction to provide the same  
authorization flexibility enjoyed by Sender-ID (which may require many  
transactions), but without path registration issues, key exchanges, or  
domain delegations.

Some people in the WG seem to have difficulty accepting that DKIM/ADSP  
is not about making strong assertions of the author identities.  This  
resistance can be easily seen when comparing this draft to SSP-03.   
DKIM is about allowing the domain to demonstrate their role.  In the  
case of ADSP, it is the Author Domain and not the Author being  
evaluated.  It is up to the Author Key Domain what gets signed and on  
who's behalf.

>> The problem that SPF sans Sender-ID hoped to solve is more safely  
>> handled by adoption of RFC3834.
>
> Actually the problem tackled by RFC 4408, i.e. backscatter, would  
> defeat the core of 2821bis, RFC 3834, and RFC 5230, where it is not  
> solved.  As nothing else offers a general solution - ignoring the  
> obsolete reverse routes in STD 10 - everybody is free to use a  
> crystal ball or SPF to judge an envelope return address, as the  
> known precondition to make 2821bis and RFC 3834 work as designed.

Disagree.  RFC3834 allows content of the message to be eliminated in  
most cases.  Such elimination removes incentives to exploit those  
willing to issue DSNs.  Of course diagnostic information should be  
included to offer some insight as to the reason, such as policy, size,  
or incompatible format etc.

> And I'd wish that one of my providers would at least use a crystal  
> ball instead of accepting fake bounces allegedly from [email-masked] 
>  with ZIPped worms => not all rubbish requires SPF, a minimal IQ can  
> also help.

Had this problem been dealt with by the IETF instead of closing the  
WG, what remained would likely have meet most of your expectations  
safely.  Except of course this might not be the same for someone who  
expected forwarding to still function as it had. : )

> In that particular case I fear they'd end up with "it is from me, I  
> trust me", and continue to dump the worms in my mailbox.  SpamCop  
> always informs me that the open proxies are known.  Stupidity is  
> certainly a major factor wrt mail.

Some may consider a DSN that does not adhere to RFC3834 and that  
includes the original spam to be treated as if the client originated  
the message when deciding what goes onto temporary blocking lists.   
For us, this would likely require a portal selection to allow each  
domain a means to make this decision for themselves.  There are  
several schools and large organizations that have had their valid  
recipients lists discovered and heavily exploited, where even SPF and  
filtering fails to offer a level of relief they had hope to obtain  
with respect to DSNs.  Perhaps a slowly changing BATV or something  
like a TPA extension that covers the MAILFROM might eventually offer a  
solution, especially when domains adhere to ADSP requirements.

> Folks could manage to decorate open proxies with a PASS :-( But at  
> least any bounces would then hit the stupid party.

We are still giving bad actors more bullets while also ensuring our  
hands are tied and our eyes are blindfolded. : (

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 27 Jun 2008 10:00:11 +0200

> The DKIM/ADSP DDoS concern is analogous to that of Sender-ID.

ADSP needs at most one DNS query for an existing domain, there
is no "analogy" to spf2.0/pra.  If you are worried about a From
header field with hundreds of addresses below a victim domain
we write "don't do this" in the ADSP security considerations.

> Sender-ID allows an override by version 2

As always your hermetic terminology beats me.  spf2.0/pra is 
one of five existing tags (or subtypes) for SPF records, and
three of them are in practice pointless:

v=spf1            RFC 4408, about SMTP HELO + MAIL FROM
spf2.0/mfrom      RFC 4406, theoretical construct, normative
                  reference to 4408, i.e. the classic v=spf1
spf2.0/mfrom,pra  RFC 4406, same as spf2.0/pra,mfrom
spf2.0/pra,mfrom  RFC 4406, same as spf2.0/pra + v=spf1
spf2.0/pra        RFC 4406, about RFC 4407 PRA

Together with the stillborn v=spf1 op=pra in an expired I-D
that's in practice two relevant subtypes, PRA or classic SPF.

There is no such thing as an "override by version 2" for PRA,
and the four subtypes in Sender-ID all start with "spf2.0",
if you consider that as "version 2".

> The relevant concern is whether a bad actor can influence
> the PRA

Bad actors pick whatever PRA, 2822-From, HELO, or MAIL FROM
suits them.  It's the job of v=spf1, spf2.0/pra, or ADSP to
defeat that.  

And because spf2.0/pra works only at border MTAs, with the
known limitation of v=spf1 for SMTP forwarding, *plus* new
requirements for any forwarder and mailing list to update
the PRA (i.e. manipulate the message proper, not only the
envelope), *minus* the advantages of v=spf1 for a PASS, it
might turn out that sp2.0/pra is "less sexy" than ADSP for
receivers.  Or maybe not, we'll know that in some years...

> Of course, bad actors would also have their messages 
> receive a Sender-ID and/or MAILFROM PASS authorization.

Or an ADSP signature.  Bad actors do with their addresses
what they like, the idea of v=spf1, spf2.0/pra, or ADSP is
that they can't do this with FAIL-protected addresses (for
FAIL read "suspicious", "locked", "discardable", or the
term du jour used in ADSP).

BTW, a MAIL FROM PASS is no "authorization", it only means
that a bounce will hit a party responsible for publishing
a PASS-policy for the relevant domain.  

Receivers can use a PASS or "good signature" to mean more 
in conjunction with a white list or reputation system, but
that is entirely under their control.  A PRA PASS from an
unknown stranger means nothing, let alone "authorization".
Ditto "good signature" from unknown stranger.
 
> A customer's message determines the PRA in various ways
> where macros, rather than DNS records directly, might do
> the bulk of the damage.

There is exactly one way to determine the PRA, and it is
specified in RFC 4407, for folks who don't find the very
simple idea in 2822upd.  The evaluation of spf2.0/pra has
exactly the same processing limits as v=spf1 in RFC 4408,
by a normative reference in RFC 4406.  

RFC 4406 boils down to "maybe using the RFC 4407 PRA would
be cute, instead of a 2821bis MAIL FROM".  This "hack" is
so lousy that it does not even bother to specify what to
do with a 2821bis HELO and %{h} macros - an integral part
of RFC 4408, but an oddity in the context of PRA.  Ignore
spf2.0/pra, like most folks not forced to care about it.

That ADSP fails miserably for Resent-From scenarios, and
arguably in violation of the 2822upd e-mail architecture,
that is interesting for this WG.  IMHO anybody trying to
outsmart RFC 4407 so far dropped the ball, including ADSP,
but "you" want to try it anyway, let's see what happens...

> Freedoms are lost due to Sender-ID exploits.

...even if that would be the case, what has it to do with
ADSP or DKIM ?  ADSP "eliminates the Resent-From freedom"
and violates 282upd.  So what, there is already an appeal
against a similar issue in PRA on public record.  And in
comparison PRA was harmless, ADSP is a frontal assault on
2822upd Resent-*.

We know this.  Repeating it for the 1001st time is boring,
let's keep our ammo for the IETF Last Call + appeal(s).

> Some people in the WG seem to have difficulty accepting
> that DKIM/ADSP is not about making strong assertions of
> the author identities.

IMO it's more like "some people consider DKIM as pointless
without strong assertions", because they don't send the
volume of mails to make their DKIM signatures interesting
for white listing by important receivers (including cases
such as ironport).

Without the chance to reject mails checking signatures of
unknown strangers is not very interesting for receivers.

> RFC3834 allows content of the message to be eliminated
> in most cases.

That's not the case.  If some POP3 users dig through the
backscatter with TOP they'd still have to deal with the
header.  Let's say that worldwide adoption of RFC 3834
Auto-Submit is "not yet ready", and besides folks want
also the body of good (= no backscatter) auto replies.

> Had this problem been dealt with by the IETF instead
> of closing the WG, what remained would likely have
> meet most of your expectations safely.

Maybe, or as Wayne said, a huge mistake.  I let the AD
talk me out of an appeal, because I had no idea for a
"remedy" (hours after I figured out that there is an
appeal procedure, as expected, and an RFC specifying
the proper procedure to terminate an IETF WG).  That's
now ancient history, R.I.P.

> of course this might not be the same for someone who  

For values of "had" between 1123 and 440x, not older.

> Some may consider a DSN that does not adhere to 
> RFC3834 and that includes the original spam to be
> treated as if the client originated the message

Just in case:  RFC 3834 is a PS about auto-replies,
not about DSNs (3461..3464, DS), and not about MDNs.
  
All use the envelope sender address of the alleged
sender, typically with an empty return address in
their various "auto" activities.  For DSNs replace
typically by MUST, loops are bad.

> There are several schools and large organizations
> that have had their valid  recipients lists 
> discovered and heavily exploited, where even SPF
> and filtering fails to offer a level of relief
> they had hope to obtain with respect to DSNs.

Spammers are lazy like everybody else, they don't
remove SPF FAIL protected addresses from their list
of "plausible + unprotected" addresses daily.  "My"
spammer (back in 2004) needed four months to get
the idea (assuming that is what happened) of FAIL.

In 2005 "he" (or somebody else) tested again for a
week to abuse @xyzzy addresses, after that I had no
backscatter issues.  Since November 2007 the @xyzzy
catch-all is closed (due to spam masses, not due to
backscatter), and on my other addresses I have no
backscatter issues (one is FAIL-protected, Gmail has
only PASS, a third has nothing - that's the somewhat
clueless provider I talked about, who accepts fake
bounces.  Nobody needs SPF FAIL to avoid this, but
it would work - HELO freenet, fix this).

Sure, if backscatter victims want immediate effects
(on their side) and have all outgoing routes under
their control, they can combine FAIL with BATV, or
try pure BATV without FAIL (bad for primary victims,
good for forwarding obstacles).  

But without FAIL the spammers have no incentive to
remove the unprotected address from their list, so
I wouldn't recommend pure BATV for these reasons.

 Frank

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Fri, 27 Jun 2008 13:27:46 -0400

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Frank Ellermann
> Sent: Friday, June 27, 2008 4:00 AM
> To: [email-masked]
> Subject: [ietf-dkim] ADSP takes DNS down,film@11 (was: bot-net concern
> explained)
> 
> 

And spf2.0/pra fails to do that. The requirement to set PRA to the
sender field if a proper one exists bypasses the SPF record intentions
of the domain represented in the RFC2822 From field email address. It is
rather trivial to game PRA to get a neutral for any particular piece of
"bad" email. But what does this have to do with DKIM and ADSP other than
the suggestion at an earlier point in the process to use the sender
field?

> term du jour used in ADSP).

Actually, with spf2.0/pra they can by avoiding the FAIL on the From by
getting NEUTRAL on the Sender.

I'm tired and I'm just going to avoid dealing with the rest of Franks
post.

Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 27 Jun 2008 17:12:08 -0700

On Jun 27, 2008, at 1:00 AM, Frank Ellermann wrote:

> ADSP needs at most one DNS query for an existing domain, there is no  
> "analogy" to spf2.0/pra.  If you are worried about a From header  
> field with hundreds of addresses below a victim domain we write  
> "don't do this" in the ADSP security considerations.

Briefly, Sender-ID enables an exploit for bad actors that are able to  
influence the PRA.  This exploit allows ten target-able transactions  
per received message using virtually none of their own resources,  
beyond that used to issue the message to provider's outbound servers.  
The size of the attack could be further increased when bad actors use  
their own resources to issue DNS records, but with an amplification of  
10 or more.  So how can ADSP/DKIM be analogous you ask.

ADSP is about accepting messages when there is no valid Author Key  
Domain signature.  There still may be signatures contained in the  
message.  While it will be unusual to have multiple From header email- 
addresses, having multiple DKIM signatures will not be.  This means a  
message may be expected to generate several additional target-able  
transactions made by receiving hosts and MUAs who evaluate DKIM  
message signing.  Of course, unsigned messages are limited to  
transactions needed to discover ADSP records.  The otis-dkim-adsp  
draft requires one compared to SSP-03 draft's of three discovery  
transactions.  The SSP-03 additional transactions was to reduce the  
number of records a phished domain feels they need to publish.  John  
Levine's replacement for this also uses three.  With all the undesired  
transactions spewing from SMTP receivers, IMHO, only the MX record  
should ever be checked or the Internet will suffer.

There will also be at least one target-able transaction for each  
signature validation attempted.  The SSP-03 draft _requires_ multiple  
signatures to comply with its definition of a valid signature whenever  
a domain wishes to indicate an on-behalf-of identity that is not the  
Author Address.  This identity might be found in the Sender or Resent- 
 From header for example.  It is hard to predict the future use of  
multiple From headers.  The number used could be influenced by email- 
address internationalization or DKIM validation constraints.  Allowing  
even one additional From email-address will have DKIM provide a number  
of free target-able transactions that approach that of Sender-ID.  Of  
course, there is still going to be Sender-ID transactions made when  
DKIM fails, for domains that do not have a LOCKED ADSP record.  : (

> As always your hermetic terminology beats me.  spf2.0/pra is one of  
> five existing tags (or subtypes) for SPF records, and three of them  
> are in practice pointless:
>

The breakdown needs to include the PRA for this version as well.  The  
experimental RFC4406 (Sender-ID) made a point to include "v=spf1".   
The Microsoft's documentation clearly promotes Sender-ID without  
warning about potential DDoS concerns or record misuse.  It blithely  
touts the number of organizations (with large networks) evaluating  
PRAs per their recommendations.  This would not be the first time  
potential misuse of a macro expanded record was, with malice of  
forethought, overlooked. : (

> There is no such thing as an "override by version 2" for PRA, and  
> the four subtypes in Sender-ID all start with "spf2.0", if you  
> consider that as "version 2".

The version 2 reference was for RFC4406 "spf2.0/<scope list>" records  
having otherwise the same syntax as version 1.  Version 2 might  
override the scope defaulted by RFC4406 for version 1 to prohibit PRA  
evaluation, but it seems doubtful a provider would do so, nor is there  
a means to really ensure PRA exclusions.

>> The relevant concern is whether a bad actor can influence the PRA
>
> Bad actors pick whatever PRA, 2822-From, HELO, or MAIL FROM suits  
> them.  It's the job of v=spf1, spf2.0/pra, or ADSP to defeat that.

The issue is about target-able undesired traffic that bad actors  
generate when exploiting both receiving host and recipient resources.   
When evaluation proceeds until something acceptable is discovered,  
then cases that generate undesired traffic that could be part of a  
distributed attack are likely ignored.

> And because spf2.0/pra works only at border MTAs, with the known  
> limitation of v=spf1 for SMTP forwarding, *plus* new requirements  
> for any forwarder and mailing list to update the PRA (i.e.  
> manipulate the message proper, not only the envelope), *minus* the  
> advantages of v=spf1 for a PASS, it might turn out that sp2.0/pra is  
> "less sexy" than ADSP for receivers.  Or maybe not, we'll know that  
> in some years...

The Internet should not be held hostage by bad actors exploiting  
poorly considered authorization or authentication schemes.  Retaining  
a functional email system and Internet depends upon behavioural  
tracking.  This tracking could be dramatically improved when it can  
reliably recognize bot-net 0wned systems.  This tracking should not  
need to depend upon the deep pockets needed to sustain reception of  
undesired traffic generated by poorly considered authorization or  
authentication efforts.  Unfortunately, SSP-03 fails to consider what  
might occur when dealing with bot-nets, and likely source of undesired  
traffic, and how it can mitigated.  Unfortunately, this is a real  
problem.

>> Of course, bad actors would also have their messages receive a  
>> Sender-ID and/or MAILFROM PASS authorization.
>
> Or an ADSP signature.  Bad actors do with their addresses what they  
> like, the idea of v=spf1, spf2.0/pra, or ADSP is that they can't do  
> this with FAIL-protected addresses (for FAIL read "suspicious",  
> "locked", "discardable", or the term du jour used in ADSP).

Agreed.

> BTW, a MAIL FROM PASS is no "authorization", it only means that a  
> bounce will hit a party responsible for publishing a PASS-policy for  
> the relevant domain.

At least I am not calling it Authentication as you know who does. : )

> Receivers can use a PASS or "good signature" to mean more in  
> conjunction with a white list or reputation system, but that is  
> entirely under their control.  A PRA PASS from an unknown stranger  
> means nothing, let alone "authorization". Ditto "good signature"  
> from unknown stranger.

Agreed.

>> A customer's message determines the PRA in various ways where  
>> macros, rather than DNS records directly, might do the bulk of the  
>> damage.
>
> There is exactly one way to determine the PRA, and it is specified  
> in RFC 4407, for folks who don't find the very simple idea in  
> 2822upd.  The evaluation of spf2.0/pra has exactly the same  
> processing limits as v=spf1 in RFC 4408, by a normative reference in  
> RFC 4406.
>
> RFC 4406 boils down to "maybe using the RFC 4407 PRA would be cute,  
> instead of a 2821bis MAIL FROM".  This "hack" is so lousy that it  
> does not even bother to specify what to do with a 2821bis HELO and % 
> {h} macros - an integral part of RFC 4408, but an oddity in the  
> context of PRA.  Ignore spf2.0/pra, like most folks not forced to  
> care about it.

Unfortunately, bad actors are able to exploit providers that do not  
ensure PRAs are not influenced. : (

> That ADSP fails miserably for Resent-From scenarios, and arguably in  
> violation of the 2822upd e-mail architecture, that is interesting  
> for this WG.

Except for the few situations where a LOCKED ADSP record might be  
used, ADSP only helps email filters make better guesses about these  
issues.  Would you see that as a failure?

> IMHO anybody trying to outsmart RFC 4407 so far dropped the ball,  
> including ADSP, but "you" want to try it anyway, let's see what  
> happens...

Phishing or spoofing prevention must be based upon something a  
recipient sees, or can use for folder placement.  Basing a protection  
scheme on something like PRA creates the same phishing holes that  
Sender-ID has.  The basic premise is that only a few domains will  
assert LOCKED ADSP records.  Sender-ID and PRA requires a mail filter  
to somehow know which From/Sender headers are likely phished.   
However, not all MUAs even display the Sender field or for that  
matter, the email-address itself.  A bad actor is able to use Resent-*  
and sometimes even Sender headers to have their messages accepted with  
a Sender-ID PASS and still deceive a recipient.

ADSP, on the other hand, takes a different tact.  Since a mail  
filtering engine is still needed, ADSP provides filter information  
about the initial state of a message.  When the domain asserts a  
CLOSED ADSP record, then a mail filter is likely to expect evidence as  
to why a signature is now missing or invalid.  The filtering can then  
weigh the strength of that evidence.  Even without a mail filter,  
there is also annotation.  Messages from a trusted domain with a valid  
signature can be annotated, while those messages without a valid  
signature would not receive the annotation.  It seems ADSP provides a  
simpler and safer scheme for protecting recipients.

The otis-dkim-adsp draft does not dictate which local-part identity is  
to be included within the signature.  It indicates the domain's  
practice assertion pertains to messages where this domain is within  
the From header.

> ...even if that would be the case, what has it to do with ADSP or  
> DKIM ?  ADSP "eliminates the Resent-From freedom" and violates  
> 282upd.  So what, there is already an appeal against a similar issue  
> in PRA on public record.  And in comparison PRA was harmless, ADSP  
> is a frontal assault on 2822upd Resent-*.

Are you suggesting ADSP should be be based upon PRA handling?  Please  
note that the DDoS and bot-net tracking concern has nothing to do with  
what field a practice assertiion is based.  The desire is to ensure  
that a direct DKIM signature indicates the signed on-behalf-of  
identity, and not that it be considered invalid when this identity is  
not that of the Author.  The domain and not the author is what people  
are likely to trust, and when the domain's signature affirms the  
identity of the Author, the Author can obtain some "special"  
annotation.  Hopefully ADSP will not limit one's ability to include  
other headers, except in rare cases where a domain publishes a LOCKED  
ADSP record.

> We know this.  Repeating it for the 1001st time is boring, let's  
> keep our ammo for the IETF Last Call + appeal(s).

It is hard to kill such a well funded and well promoted experiment  
gone bad...

>> Some people in the WG seem to have difficulty accepting that DKIM/ 
>> ADSP is not about making strong assertions of the author identities.
>
> IMO it's more like "some people consider DKIM as pointless without  
> strong assertions", because they don't send the volume of mails to  
> make their DKIM signatures interesting for white listing by  
> important receivers (including cases such as ironport).
>
> Without the chance to reject mails checking signatures of unknown  
> strangers is not very interesting for receivers.

A LOCKED ADSP assertion would permit the rejection of emails.  It  
would not be surprising to find DKIM is only checked when there is  
such an opportunity, since this assertion would be a strong indication  
of there being a problem DKIM is attempting to solve.  The identity of  
the author would be completely irrelevant, since whoever the author  
might be, whether there is a signature added is what matters for the  
message to be dismissed.

>> RFC3834 allows content of the message to be eliminated in most cases.
>
> That's not the case.  If some POP3 users dig through the backscatter  
> with TOP they'd still have to deal with the header.  Let's say that  
> worldwide adoption of RFC 3834 Auto-Submit is "not yet ready", and  
> besides folks want also the body of good (= no backscatter) auto  
> replies.

Sorry, the concern is about including the original spam, and not that  
of an auto-reply.  False positive rates should be low enough to  
protect these types of messages.

>> safely.
> Maybe, or as Wayne said, a huge mistake.  I let the AD talk me out  
> of an appeal, because I had no idea for a "remedy" (hours after I  
> figured out that there is an appeal procedure, as expected, and an  
> RFC specifying the proper procedure to terminate an IETF WG).   
> That's now ancient history, R.I.P.

As with laws and sausages, specifications seem to fall into the same  
category as things that people should not watch being made.

>> includes the original spam to be treated as if the client  
>> originated the message
>
> Just in case:  RFC 3834 is a PS about auto-replies, not about DSNs  
> (3461..3464, DS), and not about MDNs.
>
> All use the envelope sender address of the alleged sender, typically  
> with an empty return address in their various "auto" activities.   
> For DSNs replace typically by MUST, loops are bad.

You are right, but RFC3834 is a nice reference since it links to more  
specific RFCs regarding the other types of responses.

-Doug

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 28 Jun 2008 12:02:45 +0200

> And spf2.0/pra fails to do that. The requirement to set PRA
> to the sender field if a proper one exists bypasses the SPF
> record intentions of the domain represented in the RFC2822
> From field email address.

They picked "Sender ID" as name for their idea, originally it
was "Caller ID", but never "Author Domain ID".  In a certain
sense RFC 4407 is compatible with 2822(upd) Resent-*, and it
protects a Purportable Responsilbe Address, not the author(s).

> It is rather trivial to game PRA to get a neutral for any
> particular piece of "bad" email. 

Yes, and it won't surprise you that I don't like spf2.0/pra,
putting it very mildly.  But two proposals to remove Resent-*
from the picture got no traction in the 2822upd discussions.

> But what does this have to do with DKIM and ADSP other
> than the suggestion at an earlier point in the process to
> use the sender field?

Better ask Doug.  I can see Resent-* as obstacle, PRA took it
as given, ADSP ignores it, RFC 5016 section 4.3 mentions it.

 Frank

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 28 Jun 2008 13:17:03 +0200

> Briefly, Sender-ID enables an exploit for bad actors that are
> able to influence the PRA.

Doug, that's all fine, and if you want several MBs of arguments
against RFC 4406 you know where to find them, www.openspf.org
and the IAB appeal come to mind.  So far none of the ADSP drafts
says "updates: 4406", writing a 4406bis isn't in the WG Charter,
only Murrays's Auth-header draft does as much as reference 4406
(IMO correctly, YMMV).

> So how can ADSP/DKIM be analogous you ask.

Actually I disputed it.
 
> While it will be unusual to have multiple From header email- 
> addresses, having multiple DKIM signatures will not be.  This
> means a message may be expected to generate several additional
> target-able transactions made by receiving hosts and MUAs who
> evaluate DKIM message signing.

Nobody is required to check ADSP for a valid existing signature.
If you want "signature processing limits" put them in 4871bis.

> otis-dkim-adsp draft requires one compared to SSP-03 draft's
> of three discovery transactions.

SSP-03 does not yet reflect the outcome of two polls reducing
*two* to in essence *one* for existing or "mailable" domains.

> John Levine's replacement for this also uses three.

Existing domain + plus practise is two, an optional "mailable"
check can take at most three queries replacing the NXDOMAIN
check.  That is at most four queries, and folks can skip AAAA
if they judge it as irrelevant for their purposes.

> IMHO, only the MX record should ever be checked or the
> Internet will suffer.

Receivers will do what they want to determine "mailable", and
that is as it should be.  They can also use RFC 4407 if they
don't grok "envelope sender" in RFC 346x, 3834, 4408, 2821bis,
and so on.  Or if they like PRA better for a "visible in our
calendar outlook" effect.

> RFC4406 (Sender-ID) made a point to include "v=spf1"

RFC 4408 makes the opposite point...
  
> Microsoft

...under Godwin's law this thread is now dead ;-)  Take care,

 Frank

---

From: Douglas Otis <[email-masked]>
Date: Sun, 29 Jun 2008 08:42:53 -0700

On Jun 28, 2008, at 4:17 AM, Frank Ellermann wrote:

>> addresses, having multiple DKIM signatures will not be.  This means  
>> a message may be expected to generate several additional target- 
>> able transactions made by receiving hosts and MUAs who evaluate  
>> DKIM message signing.
>
> Nobody is required to check ADSP for a valid existing signature. If  
> you want "signature processing limits" put them in 4871bis.

SSP-03, even after changes to satisfy polling, the draft will still  
_increase_ the number of signatures that might be needed, and  
therefore processed.

When a receiving host's goal is to reject bogus email, ADSP discovery  
could be attempted for each From address lacking a valid Author Key  
Domain signature.  RFC4871 did not place a limit on the number of  
invalid signatures allowed, and stipulated that invalid signatures are  
not to be removed.  The burden of retaining a safe process has been  
left to follow-on practice schemes, especially when the scheme  
introduces a need for _additional_ signatures and multiple From checks.

A receiving host and/or recipient not happy with ADSP/DKIM results  
might then attempt to validate with Sender-ID.  Jim has said in public  
forums that he considers Sender-ID and DKIM complementary since they  
have different failure modes.  Such a statement invites the execution  
of both.  How many additional authentication/authorization  
transactions are too many to be safe?  When will the number of target- 
able transactions become a concern?  After all, email is already  
heavily abused, and what is being proposed is unlikely to impact the  
level of abuse.  Bot-net 0wned system locations remain hidden when  
DKIM signatures are forced to remain ambiguous about the on-behalf-of  
identity.

The signing identity must be that of the author only when a key has a  
restrictive local-part template.  The restrictive template indicates  
that the system is indirectly signing for the domain.  Whenever a  
restrictive template signature is not on behalf of the author, it  
should not be considered valid for the purpose of compliance or  
annotation whether or not any ADSP record is discovered.  SSP-03  
ignores restrictive template signatures when there is no ADSP record.   
SSP-03 also fails to recognize a directly signed signature on-behalf- 
of a different identity.  When directly signed (as denoted by a non- 
restrictive local-part template), a signature safely indicates which  
identity had been authenticated, even when found nowhere or elsewhere  
within the message.

Non-restrictive templates would represent signatures directly applied,  
where it can be assumed the message is complaint with the Author Key  
Domain policies.  Such non-restrictive signatures would be complaint  
when the Author Address is from the same domain regardless of ADSP,  
but a different domain in the Author Address would need to be have an  
OPEN ADSP assertion for full compliance.  This would allow a single  
signature to be used when an office admin that might be noted in the  
Sender header posts a message that purports to be from their boss.  As  
always, it would behove the signing system to check message compliance  
prior to adding their direct signature.

>> otis-dkim-adsp draft requires one compared to SSP-03 draft's of  
>> three discovery transactions.
>
> SSP-03 does not yet reflect the outcome of two polls reducing *two*  
> to in essence *one* for existing or "mailable" domains.

True.

> Existing domain + plus practise is two, an optional "mailable" check  
> can take at most three queries replacing the NXDOMAIN check.  That  
> is at most four queries, and folks can skip AAAA if they judge it as  
> irrelevant for their purposes.

You're right, but the hope would be that AAAA records, lacking either  
A or MX, as an acceptance check could be excluded by fiat. Such an  
exclusion would reduce the number of transactions needed and the  
number of domains afflicted by additional email transactions.   
Eventually, basing acceptance upon finding an MX record would make a  
further reduction, but importantly, would protect all domains not  
publishing an MX records from the additional email transactions that  
all the last ditch efforts such as Sender-ID, and DKIM have added.

-Doug