DomainKeys Identified Mail (DKIM) Signatures
RFC 4871

Note: This ballot was opened for revision 10 and is now closed.

(Sam Hartman) (was Discuss) Yes

Comment (2007-01-28)
No email
send info
I think this specification is an important step in exploring how to
deal with unwanted email.  I'm not sure how that exploration will work
out; I'm not sure that this technology will ultimately be useful.
However I am sure that the exploration will be useful and this spec
meets the goals of  a proposed standard in that space.
So I'm voting yes.
Thanks for addressing my discuss comments.

(Russ Housley) Yes

(Jari Arkko) No Objection

(Ross Callon) No Objection

(Brian Carpenter) No Objection

Comment (2006-12-08 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
6.2  Communicate Verification Results

   Verifiers wishing to communicate the results of verification to other
   parts of the mail system may do so in whatever manner they see fit.
   For example, implementations might choose to add an email header
   field to the message before passing it on.

What, not even a RECOMMENDED minimal header to communicate this,
like DKIM-verified: OK or DKIM-verified: Fail?

A de facto standard for this seems highly desirable. There is
no particular 1:1 relationship between MTA and MUA, and a user
who switches routinely between MTAs will be put in difficulty if
each MTA handles this differently.

Also, how about a note that this mechanism assumes that the MUA
trusts the verifier, and that DKIM does nothing to secure
that relationship?

(Lisa Dusseault) (was Discuss) No Objection

(Lars Eggert) No Objection

Comment (2006-12-11 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Appendix A., paragraph 9:
>    Received: from dsl-10.2.3.4.football.example.com  [10.2.3.4]

  Should use 192.0.2.0/24 - the block assigned as "TEST-NET" for use in
  documentation and example code. (Also elsewhere in these examples.)


Section 1.3, paragraph 2:
>    The DNS is proposed as the initial mechanism for the public keys.
>    Thus, DKIM currently depends on DNS adminstration and the security of

  Nit: s/adminstration/administration/


Appendix C., paragraph 14:
>    This results in signature data similar to this when represented in
>    Base64 [MIME] format:

  Nit: Not in the references - should probably cite RFC 2045/2047.

(Bill Fenner) (was Discuss) No Objection

Comment (2006-12-14)
No email
send info
The NON-NORMATIVE DISCUSSION POINT for g= actually seems like something that should be resolved, but perhaps it's OK since there probably aren't many real email addresses with stars.

Barry says my ABNF error has already been fixed in Eric's working copy, so I've cleared my DISCUSS.

(Cullen Jennings) (was Discuss) No Objection

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(Ted Hardie) Abstain

Comment (2007-01-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Very fundamentally, the number of combinations permitted by the specification is too high to expect a broadly interoperable email service using this mechanism to result.
The document notes, in its scalability section:


   DKIM is designed to support the extreme scalability requirements
   which characterize the email identification problem.  There are
   currently over 70 million domains and a much larger number of
   individual addresses.  DKIM seeks to preserve the positive aspects of
   the current email infrastructure, such as the ability for anyone to
   communicate with anyone else without introduction.

For this to work as an aid to the email service for the Internet, the 
verifier must understand any of the supported algorithms, an
unbounded variety of potentially signed headers (including the
signing of headers not actually present), two very different tolerances
for modification in band, a new canonicalization, and the relationship
among different selectors, including, potentially, a parent domain.

I understand from discussions with members of the working group
that the intent is to create a BCP which documents which bits of
this will actually be used in specific scenarios or by specific actors (e.g. 
mailing list MTAs).  As it stands this document is part way to
that BCP, but it is neither complete nor especially consistent.  I
understand that many of these elements were added after very
serious contention in the working group, as a compromise way
forward.  I think it would be far better as a prootcol document 
if it were bare bones, and the advice given were thrown out.  
Statements like these:

      INFORMATIVE OPERATIONS NOTE:  The choice of which header fields to
      sign is non-obvious.  One strategy is to sign all existing, non-
      repeatable header fields.  An alternative strategy is to sign only
      header fields that are likely to be displayed to or otherwise be
      likely to affect the processing of the message at the receiver.  A
      third strategy is to sign only "well known" headers.  Note that
      verifiers may treat unsigned header fields with extreme
      skepticism, including refusing to display them to the end user or
      even ignore the signature if it does not cover certain header
      fields.  For this reason signing fields present in the message
      such as Date, Subject, Reply-To, Sender, and all MIME header
      fields is highly advised.

fundamentally do not help interoperability, and the last sentence's
attempt to aim to take away the variability in the first three
alternatives is particularly bad.  If it is going to name 
"From, Date, Subject, Reply-to, Sender, and all MIME header fields", fine.
Saying that  there are lots of strategies and it is up to you to deal with the 
unknowable skepticism of the verifiers is a bit much.

I will not block the document on this basis, given the working group
discussion, but I strongly urge the inclusion of a forward pointer
to the BCP along with language which indicates that the deployment
advice in the document must not be taken as normative.  I also
urge the working group chairs, in the development of the BCP,
to take the more usual IETF approach of throwing out elements
for which there is no consensus, rather than including all of them
to reach one.  If there are 70 million different policies for signers
and 70 million approaches to verification, DKIM will fail and it
will hurt the Internet email service as it does so.

Some specific points:

Either this document or the subsequent BCP should includes an
Internationalization section.  As it stands, the document notes specific
instances which are subject to IDNA and includes this note:

      INFORMATIVE IMPLEMENTATION NOTE:  Although the "plain text"
      defined below (as "tag-value") only includes 7-bit characters, an
      implementation that wished to anticipate future standards would be
      advised to not preclude the use of UTF8-encoded text in tag=value
      lists.

There is likely to be considerably more needed.  The general thrust
of the EAI work will mean that there are many cases in which there
are parallel headers, one in UTF8 and one downgraded (see
draft-ietf-eai-utf8headers-02.txt).  Any downgrade which occurs after
insertion will break the base mechanism for verification, but should
retain sufficient information to determine whether it would have passed
before downgrade.  Again, blocking this document to wait for the EAI
specs would not make sense (they are targeted initially at Experimental),
but a general description of the issues of how to work within the downgrade
approach would be useful.  That aspect of the EAI mechanism is not
likely to change, even if the bits on the wire do.  (Note that the transport
conversions text in 5.3 raises similar issues)

The document already contains some text on the issues around body length
limits.  I believe the whole mechanism is problematic, though, especially without
much better guidance.  To take an extreme example, using a body length of zero
would mean that only the asserted headers (with From: mandatory and potentially
no others) were actually signed.  Anyone receiving such a message would
be able to reintroduce to the mail stream whatever they liked with that signature.  
Yet a signer aware that the message was going to a mailing list might do so in
order to handle the case of mailing lists which enclose posted messages
with informative text.  I understand the mailing list motivation which caused
this feature to be included, but it does not seem to me like the bang is worth
the buck.  If the upshot of broken signatures is that they are treated as
unsigned (which this documents asserts), having this breakage occur
seems a smaller price to pay than this complexity. This text related to the 
body length limit is also very odd:

     To avoid this attack, signers should be wary of using
      this tag, and verifiers might wish to ignore the tag or remove
      text that appears after the specified content length, perhaps
      based on other criteria.

Verifiers cannot ignore the tag and verify correctly.  Removing the
text that appears after the content length eliminates functionality; it
is also very different from the "treat as unsigned" default given elsewhere
in the text.

This MUST:

   Once the signature has been verified, that information MUST be
   conveyed to higher level systems (such as explicit allow/white lists
   and reputation systems) and/or to the end user.  If the message is
   signed on behalf of any address other than that in the From:  header
   field, the mail system SHOULD take pains to ensure that the actual
   signing identity is clear to the reader.

does not seem to be justified, or valid in many uses of DKIM at intermediate
MTAs.  Further, taking a single verified message to be evidence that
the signature/sender should be placed on a white list seems to be a policy
decision far beyond that appropriate for this document.  If I send you
a signed message that checks out, I may still be someone who deserves
to be on your blacklist for other reasons.  Even if my first message
checked out perfectly, there is no reason to short-circuit processing of
my later messages--which might not.

I also support the issues raised by Rob Austein and state that I would strongly
have preferred that a new RR be used for this.  The arguments for using
TXT are past their sell-by date by many years now, and not including it
even as an option is silly.

(David Kessens) Abstain

Comment (2007-01-10 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I agree with most of Ted's comments.

In particular, I cannot ballot a NoObjection in a situation where
the protocol designers decided to use the TXT record while there was not a 
convincing motivation to not use a new resource record.

Other comments that are not quite a DISCUSS:

In 'Abstract':

  ... either Mail Transfer Agents (MTAs) or Mail User Agents (MUAs). ...

MTA and MUA need a reference.

In section '3.3  Signing and Verification Algorithms':

      INFORMATIVE NOTE:  Although sha256 is strongly encouraged, some
      senders of low-security messages (such as routine newsletters) may
      prefer to use sha1 because of reduced CPU requirements to compute
      a sha1 hash.  In general, sha256 should always be used whenever
      possible.

Is the option of sha1 really needed? This argument doesn't sound very convincing as there is a lot of other processing for mail submission and delivery already. In addition, why would the receiving end be satisfied with this especially in the context of bulk mail.

In section '3.3.3  Key sizes':

      o  The practical constraint that large keys may not fit within a 512
         byte DNS UDP response packet

It seems a good idea to mention that this is in the context of ipv4.