Subject: Re: [ietf-dkim] AD evaluation comments for draft-ietf-dkim-ssp

From: Stephen Farrell <[email-masked]>
Date: Mon, 24 Nov 2008 10:36:25 +0000

Hi Pasi,

The authors have pushed out a new version of ADSP. [1]

I've just had a look at the diffs [2] between that and
the previous one, and they seem to have covered your
AD comments fairly well, so hopefully you'll be ok with
starting IETF LC after you've had a chance to check
their changes.

Regards,
Stephen.

[1] http://tools.ietf.org/html/draft-ietf-dkim-ssp
[2]
http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-ietf-dkim-ssp-06.txt&url2=http://tools.ietf.org/id/draft-ietf-dkim-ssp-07.txt

[email-masked] wrote:
> Hi,
> 
> I've done my AD review for draft-ietf-dkim-ssp-06, and I was happy
> to see that the document is in good shape.
> 
> I do have couple of suggestions, though. Basically all of these are of
> "the WG members probably understand what this text means, but if you
> could add couple of more words, future readers would be thankful"
> type; that is, suggestions for improving the clarity especially to
> folks who didn't read the WG discussions about the topic.
> 
> Stephen, could you as the document shepherd take the lead in
> discussing these and getting agreement on appropriate edits? 
> (in some cases, I've suggested a possible wording, but that's 
> just one starting point)
> 
> Best regards,
> Pasi
> 
> ------
> 
> - Section 3.1: to some folks, "domain" means just a single DNS name
>   "example.com"; to others, it might mean everything under
>   "example.com". I think it'd be useful to give a concrete example
>   here, saying e.g. that an ADSP record for "example.com" (stored in
>   _adsp._domainkey.example.com) does *not* apply to emails from
>   e.g. [email-masked] ; to cover that, you'd need 
>   _adsp._domainkey.www.example.com etc. (IMHO this is quite important 
>   detail that isn't currently isn't very obvious from the document.)
> 
> - Section 3.3, 1st bullet would be clearer if it said
>   "...no ADSP record is found"
> 
> - Section 3.3, 3rd bullet: this would be easier to understand if you
>   copied the text from 4.2.1 definition of "discardable" here, too.
> 
> - Section 3.3, 4th bullet: this would be easier to understand it
>   said "because it does not exist in DNS", "this is the case if
>   the domain does not exist in DNS", or something
> 
> - Section 3.3, should mention the 5th possibility of the procedure in
>   4.3: algorithm terminates without producing a result, indicating a
>   temporary failure.
> 
> - Section 4.1 says the "Tag=Value List" syntax from RFC 4871 is used,
>   but it seems there's a difference: 4871 uses "[FWS]" around the "="
>   sign, while this document uses *WSP. This is probably an intentional
>   difference (right?), but should be explicitly pointed out.
> 
> - Section 4.2.1: Since the signing practice list is extensible, the
>   text should say how an unknown value should be treated -- probably
>   same as "unknown"?
> 
> - Section 4.3, "Check Domain Scope" step: it'd be useful to explicitly
>   say something "NODATA" (rcode=0 with ANCOUNT=0), as if I recall right,
>   even some WG members were confused at some point...
> 
> - Section 4.3, "Fetch Named ADSP Record" step: it'd be useful to say
>   here that if the result is NXDOMAIN, or NOERROR with zero records, or
>   NOERROR with records that aren't valid ADSP records, the result is
>   "unknown" (is that right, BTW?)
> 
> - Section 4.3, "does not exist for mail" would benefit from 
>   rephrasing somehow (perhaps "is not a valid email domain for
>   [2821]", or something?)
> 
> - Section 4.3: would this be easier to read if you included a concrete
>   example (e.g. email message with a From line, and all the DNS lookups
>   done)? Or perhaps couple of examples?
> 
> - Section 6.1, last paragraph: to me it seems the amount of DNS
>   traffic would be less than amount of SMTP traffic, so this wouldn't
>   be a very good traffic multiplication attack? (with multiplier < 1)
>   If that's the case, perhaps would be useful to mention?
> 
> Nits:
> 
> - Title: Expand acronym DKIM 
> - References: update RFC 2821 to 5321, and 2822 to 5322 
> - Section 4.1, "the_adsp._domainkey" -> "the _adsp._domainkey"
> 
> ------
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html