Subject: [ietf-dkim] New Version Notification for draft-ietf-dkim-ssp-05 (fwd)

From: John Levine <[email-masked]>
Date: Tue, 5 Aug 2008 21:52:47 +0100 (IST)

We think that this version addresses all of the concerns brought up at the 
IETF 72 meeting, so I sure hope it's done.

R's,
John
---------- Forwarded message ----------
Date: Tue,  5 Aug 2008 13:50:13 -0700 (PDT)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for draft-ietf-dkim-ssp-05

A new version of I-D, draft-ietf-dkim-ssp-05.txt has been successfuly submitted by John Levine and posted to the IETF repository.

Filename:	 draft-ietf-dkim-ssp
Revision:	 05
Title:		 DKIM Author Domain Signing Practices (ADSP)
Creation_date:	 2008-08-05
WG ID:		 dkim
Number_of_pages: 20

Abstract:
DomainKeys Identified Mail (DKIM) defines a domain-level
authentication framework for email to permit verification of the
source and contents of messages.  This document specifies an adjunct
mechanism to aid in assessing messages that do not contain a DKIM
signature for the domain used in the author's address.  It defines a
record that can advertise whether a domain signs its outgoing mail,
and how other hosts can access that record.

The IETF Secretariat.
k
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Charles Lindsey" <[email-masked]>
Date: Thu, 07 Aug 2008 11:23:15 +0100

> IETF 72 meeting, so I sure hope it's done.

OK, after a careful read through, a few typos and one item needing  
clarification.

3.  Operation Overview

    independently on each address.  This standard does not address the
                                         ^^^^^^^^
                                         document

3.3.  ADSP Results

    An ADSP lookup for an Author Address produces one of four possible
    results:

    o  Messages from this domain might or might not have an author
       signature.  This is the default if the domain exists in the DNS
       but no record is found.

    o  All messages from this domain are signed.

    o  All messages from this domain are signed and discardable.

    o  The domain is not a valid mail domain.
       ^^^
       This

However, this whole section promises four possible results, whereas 4.2.1  
on the next page only provides three possible tags  
(unknown/all/discardable). Not enough information for four results, and  
the explanation is not given until Appendix A6. If we are not going to  
have a tag "none", then I think the last two bullets in 3.3 ought to be  
combined something like this:

    o  All messages from this domain are signed and discardable (this also
       covers the case of a domain that neve sends email at all, and hence
       never signs anything and presumably does not even publish a key).

And s/four possible/three possible/ of course.

4.3.  ADSP Lookup Procedure

    Check Domain Scope:   An ADSP checker implementation MUST determine
       whether a given Author Domain is within scope for ADSP.  Given the
       background in Section 3.1 the checker MUST decide which degree of
       approximation is acceptable.  The checker MUST return an
       appropriate error result for Author Domains that are outside the
       scope of ADSP.

I don't see how a standard can prescribe that you MUST do X when there is  
no clear definition of exactly what X means nor of how it could be done.

Also, the whole section 4.3 ends rather abruptly. Perhaps there needs to  
be some mention that, having fetched (or failed to fetch) and ADSP record  
(a process which is described in some detail), it is then up to the  
discretion of the checker what action to take as regards further handling  
of the message in the light of that ADSP record, and that such actions are  
not prescribed by this document.

6.1.  ADSP Threat Model

    Email abuse often seeks to exploit a legitimate email author's name-
    recognition among recipients, by using the author's domain name in
                                           ^^^
                                           that
    the From: header field.  ...

    ADSP checkers may perform multiple DNS lookups per Alleged Author
    Domain.  Since these lookups are driven by domain names in email
    message headers of possibly fraudulent email, legitimate ADSP
    checkers can become participants in traffic multiplication attacks.

I am not at all clear just how such an attack would work. Perhaps someone  
who knows could suggest a better wording.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Frank Ellermann" <[email-masked]>
Date: Thu, 7 Aug 2008 17:38:58 +0200

Charles Lindsey wrote:

Seconding all nits you found one quick remark:

>| ADSP checkers may perform multiple DNS lookups per Alleged Author
>| Domain.  Since these lookups are driven by domain names in email
>| message headers of possibly fraudulent email, legitimate ADSP
>| checkers can become participants in traffic multiplication attacks.

> I am not at all clear just how such an attack would work.

You'd pick a victim domain, say example.org, and receivers known
to check ADSP.  You send a huge amount of malicious mails to the
ADSP checkers (or to random receivers, hoping that some of them
check ADSP) using a botnet rented for the attack.

Each mail contains many From:-addresses at different subdomains
of example.org, preferably *long* random subdomains, the goal is
to overload the name servers for example.org with query traffic.

It's not clear if that actually works, but Doug claims for years
that it could work.  He uses a convoluted SPF scenario, and does
not like limiting factors like "ten" in this case, but ignoring
such details there is a clear amplification in SPF or here ADSP.

IOW the attacker can get third parties (receivers) to flood the
victim with long DNS queries for non-existing subdomains.  

 Frank