ietf-dkim
[Top] [All Lists]

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

2008-08-07 04:09:25
On Tue, 05 Aug 2008 21:52:47 +0100, John Levine <johnl(_at_)iecc(_dot_)com> 
wrote:

We think that this version addresses all of the concerns brought up at  
the
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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk      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

<Prev in Thread] Current Thread [Next in Thread>