[ietf-dkim] AD evaluation comments for draft-ietf-dkim-ssp
stephen.farrell at cs.tcd.ie
Mon Nov 24 02:36:25 PST 2008
The authors have pushed out a new version of ADSP. 
I've just had a look at the diffs  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
Pasi.Eronen at nokia.com wrote:
> 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,
> - 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. somebody at www.example.com ; 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
> ", 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?
> - 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
More information about the ietf-dkim