Subject: [ietf-dkim] DKIM signature can mean it's safe to generate bounce?

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Jul 2007 17:09:23 -0700

Folks,

I'm not sure whether this fits into SSP or not, since it does not seem to 
require that a record be published. However...

It seems to me that if a message has a DKIM signature and the signing domain 
matches the domain in the rfc2821.MailFrom command, then it is safe to 
generate a bounce message to that address.

By 'safe' I mean that one can be confident that the mail will not go to an 
unwitting victim of a spoofed address.

Am I missing something?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Fri, 6 Jul 2007 17:19:34 -0700

On Jul 6, 2007, at 5:09 PM, Dave Crocker wrote:

> Folks,
>
> I'm not sure whether this fits into SSP or not, since it does not  
> seem to require that a record be published. However...
>
> It seems to me that if a message has a DKIM signature and the  
> signing domain matches the domain in the rfc2821.MailFrom command,  
> then it is safe to generate a bounce message to that address.
>
> By 'safe' I mean that one can be confident that the mail will not  
> go to an unwitting victim of a spoofed address.
>
> Am I missing something?

If the mail is sent by [email-masked] (or a virus on their  
machine), with an envelope from address of [email-masked] out  
through the DKIM stamping earthlink smarthost and you generate a  
bounce, that bounce will go to Jane.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 17:24:18 -0700

> go to an unwitting victim of a spoofed address.

I made the same point in the tpa-ssp draft.  The domain within  
rfc2821.MailFrom does not need to be within the signing domain, when  
the signing domain and scope are authorized by the MailFrom domain.   
One should presume that this is conditions upon the message signature  
being valid.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 17:31:39 -0700

> bounce, that bounce will go to Jane.

Earthlink added the signature.  This falls into the same category as  
would any replay problem.  Once again, tpa-ssp helps cope with that  
issue as well.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Jul 2007 17:30:34 -0700

Steve Atkins wrote:
>> Am I missing something?
> 
> If the mail is sent by [email-masked] (or a virus on their machine), 
> with an envelope from address of [email-masked] out through the DKIM 
> stamping earthlink smarthost and you generate a bounce, that bounce will 
> go to Jane.

mumble.  yeah.  granularity of control within a domain.  not automatic.  grrr.

so, perhaps, an SSP record by the signing domain that says MailFrom is valid?

d/
-- 

   Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 06 Jul 2007 17:36:35 -0700

Steve Atkins wrote:
>> It seems to me that if a message has a DKIM signature and the signing 
>> domain matches the domain in the rfc2821.MailFrom command, then it is 
>> safe to generate a bounce message to that address.
>>
>> By 'safe' I mean that one can be confident that the mail will not go 
>> to an unwitting victim of a spoofed address.
>>
>> Am I missing something?
>
Sure, but at least it's reduced to an intra-domain problem which earthlink
has the capacity to remedy.

       Mike

---

From: John Levine <[email-masked]>
Date: 7 Jul 2007 00:47:51 -0000

>bounce, that bounce will go to Jane.

Indeed.  But does the signature mean that's OK?

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Jul 2007 17:50:06 -0700

> has the capacity to remedy.

I probably should have commented on this in my first reply to Steve:

Originating sites are not currently expected to validate return addresses. 
The scheme I've suggested means that the return address is, in fact, validated.

How can a potential bounce generator know whether this particular message has 
a validated return address?  Note that the mere presence of a DKIM signature 
does not guarantee this particular validation issue.

That's why the SSP-type record might be necessary.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Fri, 6 Jul 2007 17:55:08 -0700

> Indeed.  But does the signature mean that's OK?

No.

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 6 Jul 2007 17:58:23 -0700

> so, perhaps, an SSP record by the signing domain that says MailFrom  

Possibly. What's the problem you're trying to solve?

Cheers,
   Steve

---

From: Steve Atkins <[email-masked]>
Date: Fri, 6 Jul 2007 17:59:51 -0700

On Jul 6, 2007, at 5:31 PM, Douglas Otis wrote:

>>> signing domain matches the domain in the rfc2821.MailFrom  
>>> command, then it is safe to generate a bounce message to that  
>>> address.
>>>
> Earthlink added the signature.  This falls into the same category  
> as would any replay problem.  Once again, tpa-ssp helps cope with  
> that issue as well.

Why do you consider this a "replay problem" when there is no replay  
involved?

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 18:17:00 -0700

On Jul 6, 2007, at 5:36 PM, Michael Thomas wrote:

> Sure, but at least it's reduced to an intra-domain problem which  
> earthlink has the capacity to remedy.

Unless Earthlink uses per-user keys, Earthlink will need to wait for  
the signature to expire.  Even the costly step of invalidating per- 
user-keys is not likely to be effective at dealing with a replay   
problem.  Messages can come from any number of compromised systems  
within their network.  Nothing within DKIM offers Earthlink the  
"capacity" to safely deal with a replay problem.

TPA-SSP offers a means for recipients of Earthlink messages to better  
cope with a possible replay problem.  When a domain signing a message  
has been "authorized" as "strict", the "authorized" domain should  
also normally administer the SMTP client transmitting the message to  
a public server.  By limiting the cases of possible replay abuse,  
this containment provides the capacity to better deal with possible  
replay problem without resorting to per-user keys.

-Doug

---

From: John Levine <[email-masked]>
Date: 7 Jul 2007 01:35:29 -0000

>That's why the SSP-type record might be necessary.

Personally, I'd rather use BATV.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 06 Jul 2007 18:56:41 -0700

> Possibly. What's the problem you're trying to solve?

I really hate it when people ask pragmatic questions like that.  I mean, 
really Steve, didn't you know that value propositions are soooo pasé?

But I suppose I have to answer it:

I'm about to generate a bounce-category message.  If I'm suspicious enough of 
the original message, I might decide not to.  By way of trying to squelch bad 
bounce traffic at its source.

Given the DKIM sig and the "Return" SSP record, I'll generate it since the 
return address domain has said it's valid.

 > Personally, I'd rather use BATV.

That filters at the destination, not the source.

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Fri, 6 Jul 2007 19:14:14 -0700

On Jul 6, 2007, at 6:56 PM, Dave Crocker wrote:

> I really hate it when people ask pragmatic questions like that.  I  
> mean, really Steve, didn't you know that value propositions are  
> soooo pasé?
>
> I'm about to generate a bounce-category message.  If I'm suspicious  
> enough of the original message, I might decide not to.  By way of  
> trying to squelch bad bounce traffic at its source.
>
> Given the DKIM sig and the "Return" SSP record, I'll generate it  
> since the return address domain has said it's valid.

It really depends on the threat model.

If you're just trying to avoid random backscatter, then a header that  
says "X-Really-From: [email-masked]" in a mail with a return path  
address of [email-masked] and a DKIM signature that explicitly  
covers the "X-Really-From" header would be adequate.

The only case that won't catch effectively is the case where all the  
following are true:

   1. The return path is not that of the sender
   2. The sender maliciously adds an X-Really-From header that is  
identical to the return path
   3. The sender is an authorized user of the same domain as the  
claimed return path
   4. The ISP stamping DKIM is not aware of the X-Really-From header  
convention (so isn't removing or replacing it)
   5. The ISP stamping DKIM is signing all headers, rather than a  
fixed list

Whether that's adequate or not depends on the threat you're trying to  
defend against.

> That filters at the destination, not the source.

Unless you use the near-mythical public-key version, but that does  
just move around where you want to do the cryptography.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 22:48:44 -0700

On Jul 6, 2007, at 5:59 PM, Steve Atkins wrote:

>>>> I'm not sure whether this fits into SSP or not, since it does  
>>>> not seem to require that a record be published. However...
>>>>
>>>> By 'safe' I mean that one can be confident that the mail will  
>>>> not go to an unwitting victim of a spoofed address.
>>>>
>>>> Am I missing something?
>>>

This is a replay problem otherwise the MailFrom path would _not_ be  
involved.  There is _nothing_ to even suggest Earthlink transmitted  
the message to the server bouncing the message.

-Doug

---

From: Steve Atkins <[email-masked]>
Date: Sat, 7 Jul 2007 08:34:16 -0700

> since the return address domain has said it's valid.

Wouldn't you be better looking at the i= tag in the DKIM-Signature  
header, anyway?

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jul 2007 08:42:59 -0700

Steve Atkins wrote:
>> Given the DKIM sig and the "Return" SSP record, I'll generate it since 
>> the return address domain has said it's valid.
> 

Since it's optional, I hadn't thought to rely on it.

Since it's intent is different, I'd be concerned about *requiring* i= as the 
sole means for resolving this.

That said, if the i= is present AND it matches the rfc2821.MailFrom, then it 
does indeed seem like it closes the hole that you observed.

So the Bounce SSP record would only be needed if the domains matched and there 
were no i=.

The implied question that John L. raises -- squelch at source vs. squelch at 
destination -- is entirely valid.  I think it boils down to:  Is it worth the 
administrative, operational and computational overhead of this extra mechanism 
to prevent generation of specious bounces?

d/

-- 

   Dave Crocker

---

From: Hector Santos <[email-masked]>
Date: Sat, 07 Jul 2007 12:36:40 -0400

Dave Crocker wrote:
> Folks,
> 
> I'm not sure whether this fits into SSP or not, since it does not seem 
> to require that a record be published. However...
> 
> By 'safe' I mean that one can be confident that the mail will not go to 
> an unwitting victim of a spoofed address.
> 
> Am I missing something?

Two things:

1) Of course, 2821.MAIL FROM is not 2822.FROM,

2) BOUNCE is for non-deliverables, not "non authenticated messages."

We should be careful to mix bounce semantics.

We have the possible technical logic:

    A - Message Deliverable Status (1, 0)
    B - Message Authentication Status (1, 0, ?)

That gives you 6 possible scenarios:

   A1, B1 --> PERFECT WORLD!
   A1, B0 --> DROP, BOUNCE DOES NOT APPLY
   A1, B? --> DROP MAYBE?, BOUNCE DOES NOT APPLY
   A0, B1 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE
   A0, B0 --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE
   A0, B? --> DKIM DOES NOT APPLY, MSG NOT DELIVERABLE -> BOUNCE

Maybe you thinking DKIM STATUS REPORTING feedback concept?

In my book, RFC2822 is a 2nd stage consideration. 2821 comes first and 
for systems doing 2821 level successful checks, the BOUNCE is considered 
"USEABLE."  In other words, in order to avoid bounce attacks, the 2821 
system has to do its checks outside of 2822 considerations such as DKIM. 
  This might include SSP checking before the message is ACCEPTED at the 
DATA level, and the only type of SSP you should check for is for your 
basic SSP/DKIM violations as described in DSAP.

- NO-MAIL EXPECTATION
- NO SIGNATURE EXPECTED/BUT MSG IS SIGNED
- SIGNATURE EXPECTED/BUT MSG IS NOT SIGNED

DKIM validation is not required.

This is what we are doing in our products, and in fact, are currently 
adding the logic to our List Server where it does some rudimentary 
subscription DKIM POLICY checks.

-- 
Sincerely

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 07 Jul 2007 10:37:30 -0700

Dave Crocker wrote:
> Since it's intent is different, I'd be concerned about *requiring* i= 
> as the sole means for resolving this.
>
> That said, if the i= is present AND it matches the rfc2821.MailFrom, 
> then it does indeed seem like it closes the hole that you observed.
>
> So the Bounce SSP record would only be needed if the domains matched 
> and there were no i=.
>
> The implied question that John L. raises -- squelch at source vs. 
> squelch at destination -- is entirely valid.  I think it boils down 
> to:  Is it worth the administrative, operational and computational 
> overhead of this extra mechanism to prevent generation of specious 
> bounces?
An interesting side effect is that it would also suppress bounce messages
from mailing lists, even if they resigned. I'm not sure if this is a feature
or a bug.

       Mike

---

From: Dave Crocker <[email-masked]>
Date: Sat, 07 Jul 2007 10:55:57 -0700

Michael Thomas wrote:
> from mailing lists, even if they resigned. I'm not sure if this is a 
> feature or a bug.

I think that that will depend entirely on the way the SSP record is defined, 
much like the constraints on rfc2821.From values that are being discussed.

So, yeah, if the SSP associated with the MailFrom says "rfc2821.MailFrom" must 
match a DKIM signature, or somesuch, then a mailing list that inserts its own 
MailFrom, without adding its own signature, could break bounces.

d/
-- 

   Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 7 Jul 2007 17:05:48 -0400

On Friday 06 July 2007 20:09, Dave Crocker wrote:
> domain matches the domain in the rfc2821.MailFrom command, then it is safe
> to generate a bounce message to that address.
>

victim/domain yes.

> d/

I'm sure the protocol police would be out in force as this is a layer 
violation, but I expect if limited to the case where 2821 Mail From domain is 
the same as the signing domain it would likely be reasonably effective.

SPF Pass would (if available) give you the same or better confidence.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sat, 7 Jul 2007 14:10:18 -0700

On Jul 7, 2007, at 10:55 AM, Dave Crocker wrote:

>
>
> Michael Thomas wrote:
>> An interesting side effect is that it would also suppress bounce  
>> messages from mailing lists, even if they resigned. I'm not sure  
>> if this is a feature or a bug.
>
> I think that that will depend entirely on the way the SSP record is  
> defined, much like the constraints on rfc2821.From values that are  
> being discussed.
>
> So, yeah, if the SSP associated with the MailFrom says  
> "rfc2821.MailFrom" must match a DKIM signature, or somesuch, then a  
> mailing list that inserts its own MailFrom, without adding its own  
> signature, could break bounces.

What is lacking is a defined strategy to deal with possible replay  
abuse.  It could be assumed a signing domain has some strategy to  
handle replay abuse originating within their own domain.  This replay  
abuse can result from MailFrom bounces, or from forwarded messages.   
Traffic from mailing lists will require exceptional handling,  
especially when the message signature has not been invalidated.

BATV will not help when a message passes through a mailing list.   
BATV must also restrict where messages are allowed to originate to  
those outbound servers sharing the encoding secret.

Avoiding the initiation of a bounce independent of whether some email- 
address matches that of the MailFrom, would be to note whether the  
SMTP client was within the signing domain.  When the SMTP client is  
within the signing domain, the chance of a message being a replay  
diminishes greatly.  This would not require any email-address  
contained within the message to  match that of the signing domain.

-Doug

---

From: John Levine <[email-masked]>
Date: 8 Jul 2007 16:30:35 -0000

>signature, could break bounces.

I wouldn't worry too much about that scenario, since if anyone sets that
flag, everyone will be throwing away his mailing list mail anyway.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 08 Jul 2007 11:17:07 -0700

> flag, everyone will be throwing away his mailing list mail anyway.

I think this depends upon the definition of 'this flag' and what range of 
assertions is permits.  If it is a one-bit flag, then you are no-doubt correct.

d/
-- 

   Dave Crocker