Subject: Re: [ietf-dkim] Last Call: draft-ietf-dkim-deployment (DomainKeys Identified Mail (DKIM) Development, Deployment and Operations) to Informational RFC

From: Alessandro Vesely <[email-masked]>
Date: Fri, 04 Dec 2009 19:38:38 +0100

The IESG wrote:
> The IESG has received a request from the Domain Keys Identified Mail WG 
> (dkim) to consider the following document:
> 
> - 'DomainKeys Identified Mail (DKIM) Development, Deployment and 
>    Operations '
>    <draft-ietf-dkim-deployment-09.txt> as an Informational RFC

I have some minor comments and nits, as follows:

* In sect. 2.4, the last but one paragraph discusses the relation 
between the RFC5322.From domain part and the d= signature tag. Perhaps 
a forward reference to Section 7.3 may be helpful.

* In sect. 2.3, a paragraph says

  The challenge in using additional layers of sub-domains is whether
  the extra granularity will be useful for the assessor.  In fact,
  potentially excessive levels invite ambiguity: if the assessor does
  not take advantage of the added granularity, then what granularity
  will it use?  That ambiguity would move the use of DKIM back to the
  realm of heuristics, rather than the deterministic processing that is
  its goal.

The rhetorical question it puts is not clear until one reads the 
following sect. 4.3. I would suggest to replace it with a plainer 
explanation, such as "because assessors might unilaterally decide to 
only use some rightmost part of the identifier."

* I'm unable to understand sect. 3.4 "Third Party Signer Key 
Management and Selector Administration". It probably means that 
messages are addressed to "[email-masked]" so that the MSA 
skips signing them, and signatures will be added by the exploding MTA. 
However, it might also mean that messages are already signed on 
submission.

* Sect 3.5, 1st par, s/a public key pair/an asymmetric key pair/.

* In sect. 3.5.2, bullet 4.3, I'd s/empty "p=" field/empty public-key 
data ("p=") field/.

* Sect. 4.2 says "The signing module uses the appropriate private key 
to create one or more signatures." Adding "(see Section 6.5)" may 
help; however, sect. 6.5 doesn't specify when signatures can be 
produced using the same key. Or did that mean a DomainKey-Signature?

* Also in sect. 4.2, in "key information SHOULD NOT be hard-coded into 
software", I've been doltishly wondering whether a hard coded path 
name such as /etc/dkim.key would be considered "key information". "Key 
data" (the numeric value of a key) should be less ambiguous, or are 
those terms used interchangeably?

* Sect. 5.4 references "external reputation or accreditation services" 
without giving any examples. Isn't it worth to mention RFC5518?

* Sect. 6.2 s/i=marketing.domain.example/i=@marketing.domain.example/.

* Also in sect. 6.2, perhaps it is worth to note that parent domain 
signatures are not considered author signatures, e.g. adding "See also 
Section 7.3.2".

* In sect. 6.4, the last but one paragraph discusses third party 
signatures, but it misses an example. Mentioning that the signature 
would use "s=benefits; d=companyA.example" would make it more easily 
comparable with the paragraph that follows.

* Sect. 6.5 doesn't mention changing algorithms, as described in A.2, A.3.

* Sections 7.3.2 and 7.3.3 contain very similar text:

                          For example, if the address in the
  RFC5322.From is [email-masked], the SDID value of the author
  signature must be company.example.

and

  For example, email with an RFC5322.From address of bob@
  companyA.example MUST have an author signature where the SDID value
  is "companyA.example" or it will fail an ADSP validation.

In addition, that example is not overly explicative. A variation might 
say, e.g.
                                    For example, if the address in the
  RFC5322.From is [email-masked], the SDID value of the
  author signature must be subdomain.company.example, not the parent
  domain.

* (In sect. 7.3.3 "Appendix A" and "Appendix B" in the last but one 
paragraph get the wrong HTML link, internal to the same document. Can 
that be avoided?)

* Sect. 7.5 s/i=clienta.espa.example/i=@clienta.espa.example/.

* In sect. 8.1, the paragraph quoted below mentions "multiple address" 
as a feature of both ISPs and mail clients. Probably it is enough to 
s/mail clients/ISPs/, since mail client features are not relevant 
here. However, an ISP may just allow any RFC5322.From address (omit 
checking) or sign messages according to the address they use (possibly 
featuring 3rd party signing), and the point that distinguishes ISP-1 
from "some other ISPs" is not made.

  For example, assume Joe works for Company A and has an email address
  [email-masked].  Joe also has an ISP-1 account
  [email-masked], and he uses ISP-1's multiple address feature to
  attach his work email [email-masked] to his ISP-1 account.
  When Joe sends email from his ISP-1 account and uses
  [email-masked] as his designated RFC5322.From address, that
  email cannot have a signature with d=companya.example because the
  ISP-1 servers have no access to Company A's private key.  In ISP-1's
  case it will have an ISP-1 signature, but for some other mail clients
  offering the same multiple address feature there may be no signature
  at all on the message.

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

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 16 Dec 2009 09:03:05 -0800

On 12/16/2009 12:40 AM, Pekka Savola wrote:
> Some of the DKIM references listed as Informative seem to be required
> reading to fully understand this document and it would be better to put
> them
> under Normative References.

The draft targets Informational status.

What does it mean, for a reference to be Normative or Non-Normative, in a 
non-normative document?

Where is this explained for authors?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Eliot Lear <[email-masked]>
Date: Wed, 16 Dec 2009 22:42:09 +0100

Dave,
> What does it mean, for a reference to be Normative or Non-Normative,
> in a non-normative document?
>

Well timed question, because I just ran headlong into it with regard to
an experimental document.  Here is what the RFC Editor has to say
(ftp://ftp.rfc-editor.org/in-notes/rfc-editor/instructions2authors.txt):

   2.7 References and Citations

      An RFC will generally contain bibliographic references to other
      documents, and the body will contain citations to these
      references.  Section 4.7f specifies the format for the references
      listed at the end of the RFC body, but there is no required format
      for a citation.

      Within an RFC, references to other documents fall into two general
      categories: "normative" and "informative".  Normative references
      specify documents that must be read to understand or implement the
      technology in the new RFC, or whose technology must be present for
      the technology in the new RFC to work.  An informative reference
      is not normative; rather, it provides only additional information.
      For example, an informative reference might provide background or
      historical information.  Material in an informative reference is
      not required to implement the technology in the RFC.

      An RFC must include separate lists of normative and informative
      references (see Section 4.7f below.)  The distinction between
      normative and informative references is often important.  The IETF
      standards process and the RFC Editor publication process need to
      know whether a reference to a work in progress is normative.  A
      standards-track RFC cannot be published until all of the documents
      that it lists as normative references have been published.  In
      practice, this often results in the simultaneous publication of a
      group of interrelated RFCs.

      We recommend enclosing citations in square brackets ("[ ]").
      Simple numeric citations ("[53]") can cause confusing gaps when
      the list of references is split between normative and informative.
      A good alternative is to have two separate series, "[n1]", "[n2]",
      ... "[i1]", "[i2]" for citations to normative and informative
      references.  Other choices include author abbreviations, possibly
      a year ("[Smith93]"), and some brief encoding of the title and
      year ("[MPLS99a]").

The guidance at the beginning of the section seems to indicate that if
one needs to read something to understand the content you are
presenting, then a normative reference is in order, no matter the
intended status.  I personally think it matters less when dealing with
non-standards track documents (but then that's a general statement). 
The risk you take is that something changes underneath you before
publication if they are not now published.

Eliot