Subject: [ietf-dkim] New Issue: draft-ietf-dkim-threats-00 DKIM can be effective within the Originator's AdmD

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2006 11:40:00 -0800

,---
| 2.3.2.  Within Claimed Originator's Administrative Unit
|
| ... Since the submission of
| messages in this area generally occurs prior to the application of a
| message signature, DKIM is not directly effective against these bad
| actors.  Defense against these bad actors is dependent upon other
| means, such as proper use of firewalls, and mail submission agents
| that are configured to authenticate the sender.
'---

While currently DKIM does not offer a standardized means to both  
track and immediately revoke abuse emanating from the originating  
domain, abuse of this nature represents a substantial portion of the  
abuse problem.  The dkim-options draft illustrates mechanisms  
comprised of persistent Opaque-IDs and revocation records.  By using  
a persistent O-ID, the AdmD source of abuse can be tracked and  
readily reported by third-parties.  Resolution of the abuse is also  
made apparent by use of the revocation record.  This scheme neither  
exposes or depends upon an email-address.

http://www.ietf.org/internet-drafts/draft-otis-dkim-options-00.txt

Should be:
: Although the submission of messages may be prior to the application
: of a message signature, submissions are commonly authenticated
: internally within the AdmD by mail submission agents.  By including
: a persistent identifier within the signature, a substantial source
: for email abuse can be abated with the use of DKIM.  The identifier
: itself can be block-listed by the sending domain immediately
: without requiring the expiry of a key TTL.  Defense against bad
: actors is also improved with the proper use of firewalls and OS
: maintenance.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Jan 2006 22:13:32 +0000

Doug,

Douglas Otis wrote:
> While currently DKIM does not offer a standardized means to both track 
> and immediately revoke abuse emanating from the originating domain, 
> abuse of this nature represents a substantial portion of the abuse 
> problem.  The dkim-options draft illustrates mechanisms comprised of 
> persistent Opaque-IDs and revocation records.  By using a persistent 
> O-ID, the AdmD source of abuse can be tracked and readily reported by 
> third-parties.  Resolution of the abuse is also made apparent by use of 
> the revocation record.  This scheme neither exposes or depends upon an 
> email-address.
> 

That text is a somewhat overblown IMO and has some errors.

- "within the signature" - unless you're planning to advocate we
use a signature scheme with message recovery I expect you mean "with
the signature".

- As I pointed out previously, your O-ID is basically a message-set
revocation scheme (which may be a valid approach, but its nothing
really new sharing most characteristics with CRLs)

- I've no idea how you'd justify "substantial"

- "immediately" is pure sales-talk, every revocation scheme involves
inherent delays

- presumably you meant to say "black listed"

I expect if you were willing to rephrase along those lines you might
end up with something more people would buy into, or maybe not, but
I'm pretty sure the more sales-talk, the less likely something is to
get agreed.

Lastly, just to note in passing that even if the threats draft were
to say "using such-and-such might be a potentially useful counter
measure" that does not mean that the WG will arrive at consensus
to actually include mechanism that in the protocol - that latter
being a discussion for another day.

Regards,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2006 17:20:36 -0800

On Jan 25, 2006, at 2:13 PM, Stephen Farrell wrote:
> use a signature scheme with message recovery I expect you mean  
> "with the signature".
>

This is a real concern largely due to compromised systems.   
Unfortunately, an area difficult to control with a block-list would  
be a large domain, as this may impact millions of users.  Adjusting  
for the overall traffic is fair.  The problem this creates is that  
once all other sources are blocked, these sources then become a  
growing and significant share of what is left.

> - "immediately" is pure sales-talk, every revocation scheme involves

While indeed any revocation scheme would incur delay, when compared  
to key revocation, there is no additional self imposed delay waiting  
for a TTL to timeout in the recipient's cache.

> - presumably you meant to say "black listed"

No block-listed is a safer term from a liability perspective, and  
terminology accepted by the ASRG.

> I expect if you were willing to rephrase along those lines you  
> might end up with something more people would buy into, or maybe  
> not, but I'm pretty sure the more sales-talk, the less likely  
> something is to get agreed.

<rant>
If there was a real desire to clean up the mess, it would have  
happened years ago.  Much of this revolves around whether the scheme  
at hand holds the administrator accountable.  CSV and a PTR RR is  
able to verify succinctly both the EHLO and the MAILFROM in as little  
as 1 or maybe 2 lookups at the most, even with millions of machines  
within a common domain.  This would eliminate complex scripts,  
includes, redirects, macro-expansion, CDIR notation, three flavors of  
acceptance, and a possible need to perform 112 lookups that may still  
fall short or prematurely timeout.  The problem with the CSV approach  
is that it clearly holds the administrator accountable by identifying  
the culpable machine, rather than the hapless email-address domain  
owner. : (

The administrator can take both swift and effective action when abuse  
is reported, but this may cause costly support.  There are always  
administrators looking for schemes, no matter how complex, to hold  
the email-address domain owner accountable instead.  The email- 
address domain owner will likely remain clueless and frustrated when  
told the reason for their messages being deleted was due to _their_  
neglect in using the wrong provider.  The open-ended policies of SSP  
represent new avenues where problems may be placed unfairly onto the  
email-address domain owner at the hands of the administrators.  There  
are many subtle ways for this to happen, and the report vector  
missing from the signing domain suggests this concern is not all that  
unfounded.  The email-address domain owner will likely not have the  
necessary resources at their disposal to correct problems, or even  
understand the source of the problem.  Publishing any policy is risky  
business, and open-ended policies will likely represent the means for  
the wrong party to be unfairly held accountable.
</rant>

> measure" that does not mean that the WG will arrive at consensus to  
> actually include mechanism that in the protocol - that latter being  
> a discussion for another day.

Understood.

Amended Should be:

: Although the submission of messages may be prior to the application
: of a message signature, submissions are commonly authenticated
: internally within the AdmD by mail submission agents.  By including
: a persistent identifier within the signature header field, a
: substantial source for email abuse, that still remains after the
: application of block-lists, can be abated with the use of
: DKIM.  The identifier itself can be block-listed quickly by the
: sending domain without requiring the expiry of a key TTL.  Defense
: against bad actors is also improved with the proper use of firewalls
: and OS maintenance.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Jan 2006 16:30:33 -0800

Doug,

As I think I mentioned before, Section 2 doesn't deal with threats to
DKIM, it deals with threats in the absence of DKIM.  So this isn't the
right place to bring up opaque IDs.  Section 4.1.4 paragraph 4 discusses
the potential usage of opaque IDs, which I think is the right context.

-Jim

Douglas Otis wrote:
> third-parties.  Resolution of the abuse is also made apparent by use
> of the revocation record.  This scheme neither exposes or depends upon
> an email-address.
>