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

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Dec 2009 10:40:23 +0200 (EET)

On Mon, 30 Nov 2009, The IESG wrote:
> - 'DomainKeys Identified Mail (DKIM) Development, Deployment and
>   Operations '
>   <draft-ietf-dkim-deployment-09.txt> as an Informational RFC

Sorry for missing the LC DL by two days.

This is an assigned ops-dir review of draft-ietf-dkim-deployment-09.
The document describes DKIM usage scenarios and gives recommendations.
Quoting from the document:

                              This document provides practical tips for:
    those who are developing DKIM software, mailing list managers,
    filtering strategies based on the output from DKIM verification, and
    DNS servers; those who are deploying DKIM software, keys, mailing
    list software, and migrating from DomainKeys; and those who are
    responsible for the on-going operations of an email infrastructure
    that has deployed DKIM.

As such, this is very much an operations geared document.

Unfortunately, I have not looked into DKIM in detail so it's difficult to
say if these practical tips are are OK and answer the questions arising from
ops community deploying and developing DKIM.  I'd be more confident in this
if it was clear this had been thoroughly "tested" by these people.

Some comments below:

editorial
---------

In general, I found the use of UPPERCASE keywords somewhat misleading when
the advice given was to the operators and deployers, not to the developers
of the protocol.

It would be helpful to have an Abbreviations table up front.  There are many
non-spelled out abbreviations in the doc, or ones that are spelled out
later, not at the first instance of abbreviation.

Acknowledgedments is "TBD" even though we're at -09 version.  Remember that
its authors' responsibility to properly acknowledge "all Contributors,
including Indirect Contributors." (BCP78)

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.

In S A.1.1.1., one of the last two paragraphs appears to be 
incorrectly indented. These seem logically similar paragraphs.

An informative reference in Appendix 1 should be inserted to point to
RFC4870.

substantial
-----------

S 3.1 Private Key Management: Deployment and Ongoing Operations

.. this document describes many practises wrt private key management, with
uppercase keywords.  I'm not sure if using them is appropriate in this
context.  Some of the suggestions also seem unnecessarily strict or
impractical; e.g. that private key must not be network-accessible.  In
practise these goals may not be worth the tradeoffs.  Even in the field of
DNSSEC, where the compromise of the key is a much bigger problem than here,
the guidelines are more flexible.  See e.g. draft-ietf-dnsop-rfc4641bis-01
(S 3.6) and its predecessor document.

S 3.2:

    Ideally DNSSEC [RFC4034] SHOULD be employed in a configuration that
    provides protection against record insertion attacks and zone
    enumeration.  In the case that NSEC3 [RFC5155] records are employed
    to prevent insertion attack, the OPT-OUT flag MUST be set clear.

.. it is not obvious why OPT-OUT is a MUST NOT.  What are the tradeoffs?
I'm not sure if this document is best placed to mandate DNSSEC signing and
delegation behaviour that appears to be irrelevant from DKIM perspective.

S 5.1 Intended Scope of Use

    DKIM requires that a message with a signature that is found to be
    invalid is to be treated as if the message had not been signed at
    all.
...
    It follows that messages with
    invalid signatures SHOULD be treated no better and no worse than
    those with no signature at all.

.. if DKIM specs require the first sentence, then the last sentence is not
valid; SHOULD should be a MUST.  But I don't like the upper case here
anyway, and I'm not sure if the last sentence is even needed, given that the
first sentence of this section already specified the behaviour.

---

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

> 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

---

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