Skip to main content

DomainKeys Identified Mail (DKIM) Signatures
RFC 6376

Revision differences

Document history

Date Rev. By Action
2020-01-21
15 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
15 (System)
Received changes through RFC Editor sync (changed abstract to 'DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to …
Received changes through RFC Editor sync (changed abstract to 'DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK]')
2015-10-14
15 (System) Notify list changed from dkim-chairs@ietf.org, draft-ietf-dkim-rfc4871bis@ietf.org to (None)
2013-06-04
15 Amy Vezza New status of Internet Standard approved by the IESG
http://datatracker.ietf.org/doc/status-change-dkim-to-internetstandard/
2012-08-22
15 (System) post-migration administrative database adjustment to the Yes position for Pete Resnick
2011-09-26
15 Amy Vezza State changed to RFC Published from RFC Ed Queue.
2011-09-26
(System) Posted related IPR disclosure: Yahoo! Inc.'s Statement about IPR related to RFC 6376
2011-09-21
15 (System) RFC published
2011-07-13
15 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-07-13
15 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2011-07-13
15 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-07-13
15 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-07-12
15 (System) IANA Action state changed to In Progress
2011-07-12
15 Cindy Morgan IESG state changed to Approved-announcement sent
2011-07-12
15 Cindy Morgan IESG has approved the document
2011-07-12
15 Cindy Morgan Closed "Approve" ballot
2011-07-12
15 Cindy Morgan Approval announcement text regenerated
2011-07-12
15 Cindy Morgan Ballot writeup text changed
2011-07-12
15 Pete Resnick
[Ballot comment]
[All DISCUSS comments have been addressed]

- Section 6.1 (and subsections): This section is playing some sort of game. The beginning of 6.1 …
[Ballot comment]
[All DISCUSS comments have been addressed]

- Section 6.1 (and subsections): This section is playing some sort of game. The beginning of 6.1 describes some "statuses" and says things like, "The '(explanation)' is not normative text; it is provided solely for clarification." If it wanted to give an algorithm for Verfiers to follow, where there was a certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have been OK. But it is clear from the use of the phrasing, for example, "return PERMFAIL (signature syntax error)", the document is trying to sneak in some sort of actual APIs into the protocol spec. I think this is bogus and would much prefer that these sections be rewritten to say, "enters a PERMFAIL state", perhaps labeling each paragraph with the explanation. For example, the first paragraph of 6.1.1 could read:

  Signature syntax
 
  Implementers MUST meticulously validate the format and values in the
  DKIM-Signature header field; any inconsistency or unexpected values
  MUST cause the header field to be completely ignored and the verifier
  enters a PERMFAIL state.  Being "liberal in what you accept" is
  definitely a bad strategy in this security context.  Note however that
  this does not include the existence of unknown tags in a DKIM-Signature
  header field, which are explicitly permitted.
 
  Version compatibility
 
  Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
  header field with a "v=" tag that is inconsistent with this
  specification.

The current text is too cute by half, and I think it obfuscates the meaning.

- Section 3.10: Is this not completely redundant with the text in 3.6.1 regarding "t=s"?
2011-07-12
15 Pete Resnick [Ballot Position Update] Position for Pete Resnick has been changed to Yes from Discuss
2011-07-11
15 (System) New version available: draft-ietf-dkim-rfc4871bis-15.txt
2011-07-03
15 Sean Turner Ballot writeup text changed
2011-07-02
15 (System) Sub state has been changed to AD Follow up from New Id Needed
2011-07-02
14 (System) New version available: draft-ietf-dkim-rfc4871bis-14.txt
2011-06-30
15 Cindy Morgan Removed from agenda for telechat
2011-06-30
15 Cindy Morgan State changed to IESG Evaluation::Revised ID Needed from IESG Evaluation.
2011-06-30
15 Peter Saint-Andre
[Ballot comment]
1. It's good to see draft-ietf-dkim-implementation-report, which has
a thorough overview of the interoperability testing held in 2007.
However, that I-D does …
[Ballot comment]
1. It's good to see draft-ietf-dkim-implementation-report, which has
a thorough overview of the interoperability testing held in 2007.
However, that I-D does not discuss interoperability regarding the
clarifications in RFC 5672. Are they covered here? Does the community
have enough experience with them to enable us to say that there are at
least two interoperable implementations of RFC 5672?

2. In Section 3.2, why not reference RFC 4648, perhaps with text about
line feeds (etc.), instead of Section 6.8 of RFC 2045?

3. In Section 3.2, we might consider adding an informative reference to 
RFC 3629 with regard to UTF-8.

4. In Secton 3.6.2, we might consider adding a normative reference to 
RFC 1464 with regard to DNS TXT RRs.

5. In Section 6.1, we might consider adding an informative reference to
RFC 4732 with regard to denial of service attacks. (Also Sections 8.3,
8.7, 8.12.)

6. In Section 6.1.1, we might consider changing MAY to SHOULD here:

  Verifiers MAY ignore the DKIM-Signature header field if the domain
  used by the signer in the "d=" tag is not associated with a valid
  signing entity.  For example, signatures with "d=" values such as
  "com" and "co.uk" may be ignored.  The list of unacceptable domains
  SHOULD be configurable.

This seems like something we'd recommend, not describe as purely
optional.

7. In Section 7, "one has been obsoleted" makes it sound as if a new
tag has been defined to replace it (as in RFC 2026); we might consider
changing it to "one has been designated as historic".
2011-06-29
15 Pete Resnick
[Ballot discuss]
1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING" and section 8.1):

      INFORMATIVE IMPLEMENTATION NOTE: Using body length limits …
[Ballot discuss]
1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING" and section 8.1):

      INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
      an attack in which an attacker modifies a message to include
      content that solely benefits the attacker.  It is possible for the
      appended content to completely replace the original content in the
      end recipient's eyes, such as via alterations to the MIME
      structure or exploiting lax HTML parsing in the MUA, and to defeat
      duplicate message detection algorithms.  To avoid this attack,
      signers should be wary of using this tag, and verifiers might wish
      to ignore the tag, perhaps based on other criteria.

This is not an attack against DKIM. If the signer said, "I'm signing the first n bytes of the body of this message" and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that is outside the scope of this document. Either way, 3.4.5 and 3.5 should have forward references to 8.1. This is a security consideration, not anything "informative".

2. Section 6.1.3:

  verifiers might treat a message that contains bytes beyond the
  indicated body length with suspicion, such as by declaring the
  signature invalid (e.g., by returning PERMFAIL (unsigned content)),
  or conveying the partial verification to the policy module.

Up to the word "suspicion", fine. After that, it is complete nonsense. The signature is not invalid. If what you mean is "and may choose to treat the signature as if it were invalid (e.g., by going into the PERMFAIL state)", then say that. And again, this is trying to wrap APIs and implementations choices into the protocol.

3. Section 8.2: I don't see how this is DKIM specific. More importantly, this section doesn't explain how user private keys relate in any way to keys used in DKIM. Shouldn't this be a discussion about security of private keys in general (not just ones on user machines)?

4. Section 8.5: I don't understand what the attack here is that has anything to do with DKIM. I especially don't see why the accomplice is an essential part of the example, unless all that is meant by "accomplice" is "relay". The attack sounds like, "people can spam signed messages", which is not an attack on DKIM.

5. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., "h=...:from:from:..." on messages with one "From:" header field are leaving themselves open to this attack. The attack is not on the verifier. Additionally:

  Note that the technique for using "h=...:from:from:...", described in
  Section 8.15 below, is of no effect in the case of an attacker that
  is also the signer.

That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier.

Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.

6. Section 8.15:

  Implementers need to consider this possibility when designing their
  input handling functions.  Outright rejection of messages that
  violate the relevant standards such as [RFC5322], [RFC2045], etc.
  will interfere with delivery of legacy formats.  Instead, given such
  input, a signing module could return an error rather than generate a
  signature; a verifying module might return a syntax error code or
  arrange not to return a positive result even if the signature
  technically validates.

DKIM can perfectly well deal with the obsolete syntax. The signer can sign as many "From:" fields as the message has when signed, and add a ":from" to the "h=" tag to insure that the right number of them are verified. As in 8.14, the attack is not on DKIM per se; it's on signers that don't properly use the "h=" tag to sign those header fields that they don't want added to.

Other malformed input might cause problems for a DKIM implementation, but multiple header fields where 5322 3.6 only allows one is not that sort of attack.
2011-06-29
15 Peter Saint-Andre
[Ballot comment]
1. It's good to see draft-ietf-dkim-implementation-report, which has
a thorough overview of the interoperability testing held in 2007.
However, that I-D does …
[Ballot comment]
1. It's good to see draft-ietf-dkim-implementation-report, which has
a thorough overview of the interoperability testing held in 2007.
However, that I-D does not discuss interoperability regarding the
clarifications in RFC 5672. Are they covered here? Does the community
have enough experience with them to enable us to say that there are at
least two interoperable implementations of RFC 5672?

2. In Section 3.2, why not reference RFC 4648, perhaps with text about
line feeds (etc.), instead of Section 6.8 of RFC 2045?

3. In Section 3.2, we might consider adding an informative reference to 
RFC 3629 with regard to UTF-8.

4. In Secton 3.6.2, we might consider adding a normative reference to 
RFC 1464 with regard to DNS TXT RRs.

5. In Section 6.1, we might consider adding an informative reference to
RFC 4732 with regard to denial of service attacks. (Also Sections 8.3,
8.7, 8.12.)

6. In Section 6.1.1, we might consider changing MAY to SHOULD. This
seems like something we'd recommend, not describe as purely optional.

7. In Section 7, "one has been obsoleted" makes it sound as if a new
tag has been defined to replace it (as in RFC 2026); we might consider
changing it to "one has been designated as historic".
2011-06-29
15 Peter Saint-Andre [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Pete Resnick
[Ballot comment]
These first 15 comments are things that I think are potentially real problems, but I haven't heard enough back from the authors yet …
[Ballot comment]
These first 15 comments are things that I think are potentially real problems, but I haven't heard enough back from the authors yet to know if they are worthy of a DISCUSSion.

1. Section 2.7: I don't understand what the word "module" means in this context. It sounds like some sort of specific implementation, not part of a protocol. I don't know what it means to deliver values to a module.

2. Section 3.5:

  v= Version (MUST be included).  This tag defines the version of this
      specification that applies to the signature record.  It MUST have
      the value "1".  Note that verifiers must do a string comparison on
      this value; for example, "1" is not the same as "1.0".

What is the intention of "string comparison" here? There's no case sensitivity to worry about. There's no character encoding to worry about. Why not instead say, "Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) What is this trying to convey.

Also, the value is not listed as "plain-text".

3. Section 3.5, "h=":

        INFORMATIVE EXPLANATION: By "signing" header fields that do not
        actually exist, a signer can allow a verifier to detect
        insertion of those header fields after signing.  However, since
        a signer cannot possibly know what header fields might be
        created in the future, and that some MUAs might present header
        fields that are embedded inside a message (e.g., as a message/
        rfc822 content type), the security of this solution is not
        total.

a. I don't understand what MUAs presenting "header fields that are embedded inside a message" has to do with anything.

b. I don't know what the words, "the security of this solution is not total" are supposed to mean.

Don't you simply mean: "However, since a signer cannot possibly know what header fields might be defined in the future, this mechanism can't be used to prevent the addition of any possible unknown header fields."?

4. Section 3.5, "h=":

        INFORMATIVE EXPLANATION: The exclusion of the header field name
        and colon as well as the header field value for non-existent
        header fields allows detection of an attacker that inserts an
        actual header field with a null value.

I cannot parse that sentence. I have no idea what it means.

5. Section 3.7: "content-hash" is not defined.

6. Section 3.9:

a. Neither TEMPFAIL nor PERMAFAIL is defined at this point.

b. I have no idea what the "output of a DKIM verifier module" is supposed to mean.

I suspect that section 3.9 is at least misplaced in this document, and probably completely unnecessary as it sounds like implementation details.

7. Section 4.2, first INFORMATIVE NOTE: Why is this an informative note? It seems like good protocol adivce and therefore should say that signers SHOULD NOT sign exiting DKIM-Signauture fields.

8. Section 4.2, last paragraph: PERMFAIL is still not defined to this point.

I suspect sections 3.8 through all of section 4 belong after (or in) section 6.

9. Section 5.1: I don't know what the term "signing address" means.

10. Section 5.3:

  Therefore, a verifier
  SHOULD NOT validate a message that is not compliant with those
  specifications.

This section is about signing, not verifying. What is that sentence doing in there?

11. Section 5.4:

      INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
      header fields to be reordered (with the exception of Received
      header fields)

5322 does *not* permit header fields to be reordered. It says:

  ...header fields SHOULD NOT be reordered when a message is transported
  or transformed.  More importantly, the trace header fields and resent
  header fields MUST NOT be reordered, and SHOULD be kept in blocks
  prepended to the message.

Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit header fields to be reordered..."

12. Section 6.1:

  A verifier SHOULD NOT treat a message that has one or more bad
  signatures and no good signatures differently from a message with no
  signature at all; such treatment is a matter of local policy and is
  beyond the scope of this document.

The two clauses in that sentence seem contradictory. Is there an interoperability requirement that I not treat messages in a particular way, or is it a matter of local policy?

13. Section 6.1 (and subsections): This section is playing some sort of game. The beginning of 6.1 describes some "statuses" and says things like, "The '(explanation)' is not normative text; it is provided solely for clarification." If it wanted to give an algorithm for Verfiers to follow, where there was a certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have been OK. But it is clear from the use of the phrasing, for example, "return PERMFAIL (signature syntax error)", the document is trying to sneak in some sort of actual APIs into the protocol spec. I think this is bogus and would much prefer that these sections be rewritten to say, "enters a PERMFAIL state", perhaps labeling each paragraph with the explanation. For example, the first paragraph of 6.1.1 could read:

  Signature syntax
 
  Implementers MUST meticulously validate the format and values in the
  DKIM-Signature header field; any inconsistency or unexpected values
  MUST cause the header field to be completely ignored and the verifier
  enters a PERMFAIL state.  Being "liberal in what you accept" is
  definitely a bad strategy in this security context.  Note however that
  this does not include the existence of unknown tags in a DKIM-Signature
  header field, which are explicitly permitted.
 
  Version compatibility
 
  Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
  header field with a "v=" tag that is inconsistent with this
  specification.

The current text is too cute by half, and I think it obfuscates the meaning.

14. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: This is a security consideration instead, not an informative note. Should be a forward reference to section 8.3

15. Section 6.1.3: I don't understand the meaning of the note, "(note that this version does not actually need to be instantiated)".

These last 10 comments are simply stylistic and editorial stuff. If they make sense to fix, great. If not, I'm not concerned.

1. I find the use of the word "INFORMATIVE" throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose.

2. The ABNF "0*" construct is not normally used. Just "*" is sufficient.

3. Section 3.4.4:

      INFORMATIVE NOTE: It should be noted that the relaxed body
      canonicalization algorithm may enable certain types of extremely
      crude "ASCII Art" attacks where a message may be conveyed by
      adjusting the spacing between words.  If this is a concern, the
      "simple" body canonicalization algorithm should be used instead.

I think this MITM attack (the ability to insert and delete whitespace to send coded ASCII Art messages to the recipient) is so far fetched as to not be worthy of mention. If the WG really thinks it is worthy of mention, it should go in security considerations.

4. Section 3.5: It would be nice to subsection each tag here. (e.g., "v=" could be 3.5.1, etc.)

5. Section 3.5, "h=":

It would be nice to add a sentence similar to the one in 5.4: "The field MAY contain multiple instances of a header field name; this means that multiple occurrences of the header field are being signed by the signing algorithm."

6. Section 3.6.1: It would be nice to subsection each of the tags.

7. Section 3.10: Is this not completely redundant with the text in 3.6.1 regarding "t=s"?

8. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out as such. The title of the section is "Example Scenarios". All of the text here is example, and as such it is all informative.

9. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules may be incorporated into any", how about "A signer can be implemented as part of any"?

10. Section 5.5: Though section 5.5 is titled "Recommended Signature Content", it is clear that the entire section is devoted to the topic of section 5.4: "Determine the Header Fields to Sign". These two sections should be combined, and might be subsections of a larger section. But it was very confusing to read these as separate.
2011-06-29
15 Pete Resnick
[Ballot discuss]
1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING" and section 8.1):

      INFORMATIVE IMPLEMENTATION NOTE: Using body length limits …
[Ballot discuss]
1. Section 3.4.5 (cf. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING" and section 8.1):

      INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
      an attack in which an attacker modifies a message to include
      content that solely benefits the attacker.  It is possible for the
      appended content to completely replace the original content in the
      end recipient's eyes, such as via alterations to the MIME
      structure or exploiting lax HTML parsing in the MUA, and to defeat
      duplicate message detection algorithms.  To avoid this attack,
      signers should be wary of using this tag, and verifiers might wish
      to ignore the tag, perhaps based on other criteria.

This is not an attack against DKIM. If the signer said, "I'm signing the first n bytes of the body of this message" and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that is outside the scope of this document. Either way, 3.4.5 and 3.5 should have forward references to 8.1. This is a security consideration, not anything "informative".

2. Section 6.1.3:

  verifiers might treat a message that contains bytes beyond the
  indicated body length with suspicion, such as by declaring the
  signature invalid (e.g., by returning PERMFAIL (unsigned content)),
  or conveying the partial verification to the policy module.

Up to the word "suspicion", fine. After that, it is complete nonsense. The signature is not invalid. If what you mean is "and may choose to treat the signature as if it were invalid (e.g., by going into the PERMFAIL state)", then say that. And again, this is trying to wrap APIs and implementations choices into the protocol.

3. Section 8.2: I don't see how this is DKIM specific. More importantly, this section doesn't explain how user private keys relate in any way to keys used in DKIM. Shouldn't this be a discussion about security of private keys in general (not just ones on user machines)?

4. Section 8.5: I don't understand what the attack here is that has anything to do with DKIM. I especially don't see why the accomplice is an essential part of the example, unless all that is meant by "accomplice" is "relay". The attack sounds like, "people can spam signed messages", which is not an attack on DKIM.

5. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., "h=...:from:from:..." on messages with one "From:" header field are leaving themselves open to this attack. The attack is not on the verifier. Additionally:

  Note that the technique for using "h=...:from:from:...", described in
  Section 8.15 below, is of no effect in the case of an attacker that
  is also the signer.

That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier.

Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.

6. Section 8.15:

  However, [RFC5322] also tolerates obsolete message syntax, which does
  allow things like multiple From: fields on messages.  The
  implementation of DKIM thus potentially creates a more stringent
  layer of expectation regarding the meaning of an identity, while that
  additional meaning is either obscured from or incorrectly presented
  to an end user in this context.

DKIM can perfectly well deal with the obsolete syntax. The signer can sign as many "From:" fields as the message has when signed, and add a ":from" to the "h=" tag to insure that the right number of them are verified. As in 8.14, the attack is not on DKIM per se; it's on signers that don't properly use the "h=" tag to sign those header fields that they don't want added to.

Other malformed input might cause problems for a DKIM implementation, but multiple header fields where 5322 3.6 only allows one is not that sort of attack.
2011-06-29
15 Pete Resnick [Ballot Position Update] New position, Discuss, has been recorded
2011-06-29
15 Adrian Farrel
[Ballot comment]
I note that in Section 1.2 of RFC 4871 (May 2007) it says "there are currently over 70 million domains." So while Section …
[Ballot comment]
I note that in Section 1.2 of RFC 4871 (May 2007) it says "there are currently over 70 million domains." So while Section 1.3 of this I-D is not wrong to say "there are currently over 70 million domains," it may be a significant underestimate.

I am not completely comfortable with the use of "normative" RFC 2119 language in ABNF comments. For example...
  dkim-safe-char        =  %x21-3A / %x3C / %x3E-7E
                              ; '!' - ':', '<', '>' - '~'
                              ; Characters not listed as "mail-safe" in
                              ; [RFC2049] are also NOT RECOMMENDED.

A terrible nit, but would you consider s/may/might/ in...
  o  The practical constraint that large (e.g., 4096 bit) keys may not
      fit within a 512-byte DNS UDP response packet
2011-06-29
15 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Russ Housley [Ballot comment]
Appendix E should probably include a pointer to the errata.
  Some documents have included a URL for this purpose.
2011-06-29
15 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 David Harrington [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-06-29
15 Sean Turner State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-06-29
15 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-28
15 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-06-28
15 Amanda Baber
QUESTION: Should IANA update the reference to RFC 4871 in the Email
Authentication Methods registry? See
http://www.iana.org/assignments/email-auth

ACTION 1:

Upon approval of this document, IANA …
QUESTION: Should IANA update the reference to RFC 4871 in the Email
Authentication Methods registry? See
http://www.iana.org/assignments/email-auth

ACTION 1:

Upon approval of this document, IANA will replace the reference to RFC
4871
associated with Permanent Message Header Field Name registration
DKIM-Signature with a reference to this document. See

http://www.iana.org/assignments/message-headers/perm-headers.html

ACTION 2:

Upon approval of this document, IANA will add a "Status" column to all
registries created by RFC 4871 at
http://www.iana.org/assignments/dkim-parameters

All references to RFC 4871 will be replaced with references to this
document, except for the reference associated with the following
registration in the _domainkey DNS TXT Record Tag Specifications registry:

g | [RFC4871] | historic

Except for the "g" registration listed above, every registration in the
affected registries, regardless of reference, will have its status
listed as "active."
2011-06-28
15 Pete Resnick
[Ballot comment]
1. I find the use of the word "INFORMATIVE" throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. …
[Ballot comment]
1. I find the use of the word "INFORMATIVE" throughout the document superfluous. No other word (e.g., NORMATIVE) is used in its place. I think they should all be removed. They serve no purpose.

2. The ABNF "0*" construct is not normally used. Why not just "*"?

3. Section 2.7: I don't understand what the word "module" means in this context. It sounds like some sort of specific implementation, not part of a protocol. I don't know what it means to deliver values to a module.

4. Section 3.4.4:

      INFORMATIVE NOTE: It should be noted that the relaxed body
      canonicalization algorithm may enable certain types of extremely
      crude "ASCII Art" attacks where a message may be conveyed by
      adjusting the spacing between words.  If this is a concern, the
      "simple" body canonicalization algorithm should be used instead.

This is not an attack, or at the very least it is not an attack on DKIM. You can play this same game with MIME encodings or other textual tricks. I don't see any justification for this note being in this document.

5. Section 3.4.5:

      INFORMATIVE IMPLEMENTATION NOTE: Using body length limits enables
      an attack in which an attacker modifies a message to include
      content that solely benefits the attacker.  It is possible for the
      appended content to completely replace the original content in the
      end recipient's eyes, such as via alterations to the MIME
      structure or exploiting lax HTML parsing in the MUA, and to defeat
      duplicate message detection algorithms.  To avoid this attack,
      signers should be wary of using this tag, and verifiers might wish
      to ignore the tag, perhaps based on other criteria.

I don't understand how this is an attack. If the signer said, "I'm signing the first n bytes of the body of this message" and the verifier is able to verify that the signature is valid for n bytes of the body, the algorithm has succeeded. At most, this should lead to an admonition that unsigned data is not verified and therefore should not be trusted, but that seems obvious. There might be an attack on an MUA that does not verify the DKIM signature, but that seems outside the scope of this document.

6. Section 3.5:

  v= Version (MUST be included).  This tag defines the version of this
      specification that applies to the signature record.  It MUST have
      the value "1".  Note that verifiers must do a string comparison on
      this value; for example, "1" is not the same as "1.0".

Why "string comparison" here? There's no case sensitivity to worry about. There's no character encoding to worry about. Why not instead say, "Note that verifiers must (MUST?) ensure that the value is '1'; for exmaple '1' is not the same as '1.0'"? (Seem similar text in 3.6.1.) And why is the value not listed as "plain-text"?

7. Section 3.5: It would be nice to subsection each tag here. (e.g., "v=" could be 3.5.1, etc.)

8. Section 3.5, "h=":

It would be nice to add a sentence similar to the one in 5.4: "The field MAY contain multiple instances of a header field name; this means that multiple occurrences of the header field are being signed by the signing algorithm."

9. Section 3.5, "h=":

        INFORMATIVE EXPLANATION: By "signing" header fields that do not
        actually exist, a signer can allow a verifier to detect
        insertion of those header fields after signing.  However, since
        a signer cannot possibly know what header fields might be
        created in the future, and that some MUAs might present header
        fields that are embedded inside a message (e.g., as a message/
        rfc822 content type), the security of this solution is not
        total.

a. I don't understand what MUAs presenting "header fields that are embedded inside a message" has to do with anything.

b. I don't know what the words, "the security of this solution is not total" are supposed to mean.

Don't you simply mean: "However, since a signer cannot possibly know what header fields might be defined in the future, this mechanism can't be used to prevent the addition of any possible unknown header fields."?

10. Section 3.5, "h=":

        INFORMATIVE EXPLANATION: The exclusion of the header field name
        and colon as well as the header field value for non-existent
        header fields allows detection of an attacker that inserts an
        actual header field with a null value.

I cannot parse that sentence. I have no idea what it means.

11. Section 3.5, "l=", "INFORMATIVE IMPLEMENTATION WARNING". See comment in 3.4.5 above. Same comment.

12. Section 3.6.1: It would be nice to subsection each of the tags.

13. Section 3.7: "content-hash" is not defined.

14. Section 3.9:

a. Neither TEMPFAIL nor PERMAFAIL is defined at this point.

b. I have no idea what the "output of a DKIM verifier module" is supposed to mean.

I suspect that section 3.9 is at least misplaced in this document, and probably completely unnecessary as it sounds like implementation details.

15. Section 3.10: Is this not completely redundant with the text in 3.6.1 regarding "t=s"?

16. Section 4.1: The "INFORMATIVE EXAMPLES" don't need to be called out as such. The title of the section is "Example Scenarios". All of the text here is example, and as such it is all informative.

17. Section 4.2, first INFORMATIVE NOTE: Why is this an informative note? It seems like good protocol adivce and therefore should say that signers SHOULD NOT sign exiting DKIM-Signauture fields.

18. Section 4.2, last paragraph: PERMFAIL is still not defined to this point.

I suspect sections 3.8 through all of section 4 belong after (or in) section 6.

19. Section 5.1, INFORMATIVE NOTE: Instead of saying "Signing modules may be incorporated into any", how about "A signer can be implemented as part of any"?

20. Section 5.1: I don't know what the term "signing address" means.

21. Section 5.3:

  Therefore, a verifier
  SHOULD NOT validate a message that is not compliant with those
  specifications.

This section is about signing, not verifying. What is that sentence doing in there?

22. Section 5.4:

      INFORMATIVE ADMONITION: Despite the fact that [RFC5322] permits
      header fields to be reordered (with the exception of Received
      header fields)

5322 does *not* permit header fields to be reordered. It says:

  ...header fields SHOULD NOT be reordered when a message is transported
  or transformed.  More importantly, the trace header fields and resent
  header fields MUST NOT be reordered, and SHOULD be kept in blocks
  prepended to the message.

Suggest: "Despite the fact that [RFC5322] does not absolutely prohibit header fields to be reordered..."

23. Section 5.5: Though section 5.5 is titled "Recommended Signature Content", it is clear that the entire section is devoted to the topic of section 5.4: "Determine the Header Fields to Sign". These two sections should be combined, and might be subsections of a larger section. But it was very confusing to read these as separate.

24. Section 6.1:

  A verifier SHOULD NOT treat a message that has one or more bad
  signatures and no good signatures differently from a message with no
  signature at all; such treatment is a matter of local policy and is
  beyond the scope of this document.

The two clauses in that sentence seem contradictory. Is there an interoperability requirement that I not treat messages in a particular way, or is it a matter of local policy?

25. Section 6.1, first "INFORMATIVE NOTE" on attack by many bad sigs: Shouldn't this be a security consideration instead?

26. Section 6.1 (and subsections): This section is playing some sort of game. The beginning of 6.1 describes some "statuses" and says things like, "The '(explanation)' is not normative text; it is provided solely for clarification." If it wanted to give an algorithm for Verfiers to follow, where there was a certain state machine with states of "PERMFAIL" and "TEMPFAIL", that would have been OK. But it is clear from the use of the phrasing, for example, "return PERMFAIL (signature syntax error)", the document is trying to sneak in some sort of actual APIs into the protocol spec. I think this is bogus and would much prefer that these sections be rewritten to say, "enters a PERMFAIL state", perhaps labeling each paragraph with the explanation. For example, the first paragraph of 6.1.1 could read:

  Signature syntax
 
  Implementers MUST meticulously validate the format and values in the
  DKIM-Signature header field; any inconsistency or unexpected values
  MUST cause the header field to be completely ignored and the verifier
  enters a PERMFAIL state.  Being "liberal in what you accept" is
  definitely a bad strategy in this security context.  Note however that
  this does not include the existence of unknown tags in a DKIM-Signature
  header field, which are explicitly permitted.
 
  Version compatibility
 
  Verifiers MUST enter a PERMFAIL state when presented a DKIM-Signature
  header field with a "v=" tag that is inconsistent with this
  specification.

The current text is too cute by half, and I think it obfuscates the meaning.

27. Section 6.1.3: I don't understand the meaning of the note, "(note that this version does not actually need to be instantiated)".

28. Section 6.1.3:

  verifiers might treat a message that contains bytes beyond the
  indicated body length with suspicion, such as by declaring the
  signature invalid (e.g., by returning PERMFAIL (unsigned content)),
  or conveying the partial verification to the policy module.

Up to the word "suspicion", fine. After that, it is complete nonsense. The signature is not invalid. If what you mean is "and may choose to treat the signature as if it were invalid (e.g., by going into the PERMFAIL state)", then say that. And again, this is trying to wrap APIs and implementations choices into the protocol.

29. Section 8.1: See comments above regarding section 3.4.5.

30. Section 8.2: I don't see how this is DKIM specific. More importantly, this section doesn't explain how user private keys relate in any way to keys used in DKIM. Shouldn't this be a discussion about security of private keys in general (not just ones on user machines)?

31. Section 8.5: I don't understand what the attack here is that has anything to do with DKIM. I especially don't see why the accomplice is an essential part of the example, unless all that is meant by "accomplice" is "relay". The attack sounds like, "people can spam signed messages", which is not an attack.

32. Section 8.14: This is a complete mischaracterization of the problem. This is absolutely not an attack vector. If a signer wishes to prevent additional *known* header fields from being verified, it can simply use the technique outlined in 8.15. If the signer chooses not to do that, it is expressing the intent that it considers messages valid that have additional header fields added. *That's* the security consideration: Signers should know that failing to include, e.g., "h=...:from:from:..." on messages with one "From:" header field are leaving themselves open to this attack. The attack is not on the verifier. Additionally:

  Note that the technique for using "h=...:from:from:...", described in
  Section 8.15 below, is of no effect in the case of an attacker that
  is also the signer.

That sentence is utter nonsense. The signer *can't* be the attacker for purposes of DKIM when it comes to the header fields it's willing to sign. The Introduction (section 1) makes it absolutely clear that DKIM is about transmitting information from a signer to a verifier.

Section 8.14 needs to be completely rewritten. It is nonsensical as it stands.

33. Section 8.15:

  However, [RFC5322] also tolerates obsolete message syntax, which does
  allow things like multiple From: fields on messages.  The
  implementation of DKIM thus potentially creates a more stringent
  layer of expectation regarding the meaning of an identity, while that
  additional meaning is either obscured from or incorrectly presented
  to an end user in this context.

DKIM can perfectly well deal with the obsolete syntax. The signer can sign as many "From:" fields as the message has when signed, and add a ":from" to the "h=" tag to insure that the right number of them are verified. As in 8.14, the attack is not on DKIM per se; it's on signers that don't properly use the "h=" tag to sign those header fields that they don't want added to.

Other malformed input might cause problems for a DKIM implementation, but multiple header fields where 5322 3.6 only allows one is not that sort of attack.
2011-06-28
15 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-06-28
15 Wesley Eddy [Ballot Position Update] New position, No Objection, has been recorded
2011-06-24
13 (System) New version available: draft-ietf-dkim-rfc4871bis-13.txt
2011-06-24
15 Stephen Farrell
[Ballot comment]
Good job.

Other, than (6) & (8) below, which I'd ask that you check, I'm
entirely fine if you totally ignore these - …
[Ballot comment]
Good job.

Other, than (6) & (8) below, which I'd ask that you check, I'm
entirely fine if you totally ignore these - they're just the notes I
made as I read the thing again (after not having had to do that
for a while:-) and are basically all nitty suggestions.

(1) 2nd para of 2.6 refers to "i=" and "t=s" before those have
been introduced. I wouldn't suggest defining them here, so I'm
not sure what to change to make it better but maybe worth a look.
Maybe you could get rid of the tags though for example by saying:

  "Note that acceptable values for the AUID may be constrained via
  a flag in public key record. (See Section 3.6.1)"

(2) end of p20, maybe s/are expected to/may/ since we're doing a
new spec now but not changing the version number.

(3) 2nd last para, p23: signing non-existent header fields does
not "prevent" later insertion, it allows detection of that after
the fact. Same issue with last para on p23 as well. The change is
obvious I guess if you want to make it.

(4) p26, is "DNS TXT record" or "DNS TXT resource record" more
correct? (And if so, do we care or not:-) If the latter then the
same change would be needed in a few places.

(5) Would it be useful for the reader and/or IANA to note that
there are no new tags defined in section 7 compared to rfc4871?

(6) Is 7.9 actually correct? That IANA registry references 4871
but should that be changed to this document or left alone? I've
no idea.

(7) Could/should appendix B.2.3 have an informative reference to
dkim-mailinglists? Since that's now approved, it won't add any
significant time for the RFC editor to do those together.  (I
think.)

(8) The last paragraph of appendix C is odd - maybe the reference
in there should be to rfc4870?
2011-06-24
15 Stephen Farrell [Ballot Position Update] New position, Yes, has been recorded
2011-06-22
15 Sean Turner [Ballot Position Update] New position, Yes, has been recorded for Sean Turner
2011-06-22
15 Sean Turner Ballot has been issued
2011-06-22
15 Sean Turner Created "Approve" ballot
2011-06-22
15 Sean Turner Telechat date has been changed to 2011-06-30 from 2011-07-14
2011-06-22
15 Sean Turner Status Date has been changed to 2011-06-22 from 2011-06-15
2011-06-17
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Eric Rescorla
2011-06-17
15 Samuel Weiler Request for Last Call review by SECDIR is assigned to Eric Rescorla
2011-06-15
15 Sean Turner Placed on agenda for telechat - 2011-07-14
2011-06-15
15 Amy Vezza Last call sent
2011-06-15
15 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard


The IESG has received a request from the Domain Keys Identified Mail WG
(dkim) to consider the following document:
- 'DomainKeys Identified Mail (DKIM) Signatures'
  as a Draft Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-06-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  DomainKeys Identified Mail (DKIM) permits a person, role, or
  organization that owns the signing domain to claim some
  responsibility for a message by associating the domain with the
  message.  This can be an author's organization, an operational relay
  or one of their agents.  DKIM separates the question of the identity
  of the signer of the message from the purported author of the
  message.  Assertion of responsibility is validated through a
  cryptographic signature and querying the signer's domain directly to
  retrieve the appropriate public key.  Message transit from author to
  recipient is through relays that typically make no substantive change
  to the message content and thus preserve the DKIM signature.

  This memo obsoletes RFC4871 and RFC5672.

DIffs from RFC 4871

  Changes from RFC 4871 can be found at:
  http://www.trusteddomain.org/dkim-diff.html

DOWNREFs

  This specification contains two normative references to proposed
  standard RFCs: RFC 3447 and RFC 5890.

  This specification contains two normative references to non-IETF
  RFCs: FIPS-180-3-2008 (SHA) and ITU-X660-1997 (ASN.1).

  This specification contains one normative reference to an
  informational RFC: RFC 5598.

  This specification also contains one informative reference to a
  historical document: RFC 4870.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/

Implementation Report can be accessed at
http://www.ietf.org/iesg/implementation/report-rfc4871.txt

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/


The following IPR Declarations may be related to this I-D:

  http://datatracker.ietf.org/ipr/1547/



2011-06-15
15 Sean Turner Last Call was requested
2011-06-15
15 Sean Turner State changed to Last Call Requested from Publication Requested.
2011-06-15
15 Sean Turner Last Call text changed
2011-06-15
15 (System) Ballot writeup text was added
2011-06-15
15 (System) Last call text was added
2011-06-15
15 (System) Ballot approval text was added
2011-06-15
15 Sean Turner Last Call text changed
2011-06-15
15 Sean Turner Last Call text changed
2011-06-15
15 Sean Turner Status Date has been changed to 2011-06-15 from None
2011-06-15
15 Sean Turner Intended Status has been changed to Draft Standard from Proposed Standard
2011-06-15
15 Sean Turner Ballot writeup text changed
2011-06-15
15 Cindy Morgan [Note]: 'Barry Leiba (barryleiba@computer.org) is the document shepherd. ' added
2011-06-15
15 Cindy Morgan
PROTO writeup for draft-ietf-dkim-rfc4871bis-12

The DKIM Working Group requests the publication of draft-ietf-dkim-rfc4871bis-12 as a Draft Standard RFC, progressing RFC 4871 from Proposed to Draft …
PROTO writeup for draft-ietf-dkim-rfc4871bis-12

The DKIM Working Group requests the publication of draft-ietf-dkim-rfc4871bis-12 as a Draft Standard RFC, progressing RFC 4871 from Proposed to Draft Standard. The implementation report to support this request is http://www.ietf.org/iesg/implementation/report-rfc4871.txt.


(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Barry Leiba is the document shepherd. I have reviewed this version, and am satisfied that it's ready.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has adequate review, and I have no concerns about the level of review.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

I have no concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no personal concerns. See "Working Group Summary" for a discussion of the working group's position. I'll note here that on the surface there appear to be many text changes between RFC 4871 and 4871bis -- perhaps an unusual number for progression from PS to DS. Much of that comes from the fact that 4871 was updated by RFC 5672, and 4871bis represents the merging of those updates into the base document, along with progression to DS. The set of substantive changes beyond that merging is small, and the working group believes they are appropriate for moving DKIM to Draft Standard. These changes are listed in Appendix E. The diffs from RFC 4871 and this draft can be found (while the deliberations last) at http://www.trusteddomain.org/dkim-diff.html

The IPR statement from Yahoo! on RFC 4871 will apply to this document as well:
https://datatracker.ietf.org/ipr/920/
Yahoo! has submitted an update to apply that IPR statement to the -09 version of the draft, the version that was current when they made the update. They will update it again when the RFC is published.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is rough consensus of the working group, as a whole, behind it. Notwithstanding that, this has been a controversial process, with strong disagreement about a number of points. See the "Working Group Summary", later in this writeup, for more on this.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

One appeal has been received and another has been threatened. A response to the first appeal has been returned and the primary appellant accepted the response. It is not clear whether the co-appellants have accepted the response.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

There are no ID nits apart from some references (see 1.h).
Note that idnits 2.12.11 incorrectly declares some nits. Pay no attention to the man behind that curtain.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

All references are properly separated and labelled.
There is a normative reference to RFC 5890 (IDNA), a Proposed Standard. This reference is necessary to specify how to encode non-ASCII domain names.

There is a normative reference to RFC 5598, an informational document. This document defines terms used in discussion of email architecture, and is widely referenced in this manner.

There is an normative reference to RFC 3447 (RSA Crypto), an informational document. This is an IETF specification of externally defined algorithms. Note that this document is called out in the DOWNREF registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry

There are two normative references to non-IETF documents (FIPS-180-3-2008 (SHA) and ITU-X660-1997 (ASN.1)).

There is an informative reference to RFC 4870 (Domain Keys), a Historical document; this is correct.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA Considerations section is correct and adequate. It reflects the changes made when RFC 4871 was published, along with an update provided in this document.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The formal grammar is correct.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Getting this document finished has been a controversial process, with strong disagreement about a number of points. There is certainly broad agreement that DKIM is a widely deployed, useful protocol, and that it's ready for advancement. There are major differences of opinion on several things, including
1. The importance of giving specific advice on which email header fields to sign.
2. What information should be considered "output" from the signature verifier.
3. How the DKIM signature ties into, or should tie into, domain names that appear in other parts of the email message, particularly the RFC 5322 "from" header field.
4. How to handle potential attacks mounted by adding extra header fields to the message after it has been signed. This is a particular issue with the RFC 5322 "from" header field, but affects other header fields as well.

There have been other controversies; this list is not exhaustive. See the mailing list archives for more details. In the end, though, the document as submitted has rough and significant consensus of the working group as a whole, even when it doesn't represent unanimity.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The DKIM base protocol is widely deployed, with many implementations (see http://www.ietf.org/iesg/implementation/report-rfc4871.txt ). This version of the spec comes after a thorough working group review and publication of RFC 5672, which added significant clarifications to the language.
2011-06-15
15 Cindy Morgan Draft added in state Publication Requested
2011-06-15
12 (System) New version available: draft-ietf-dkim-rfc4871bis-12.txt
2011-06-15
11 (System) New version available: draft-ietf-dkim-rfc4871bis-11.txt
2011-05-25
15 Barry Leiba Submitted to IESG
2011-05-25
15 Barry Leiba IETF state changed to Submitted to IESG for Publication from WG Document
2011-05-25
15 Barry Leiba Changed protocol writeup
2011-05-11
10 (System) New version available: draft-ietf-dkim-rfc4871bis-10.txt
2011-05-04
(System) Posted related IPR disclosure: Yahoo! Inc.'s Statement about IPR related to RFC 4871 and draft-ietf-dkim-rfc4871bis-09
2011-05-02
09 (System) New version available: draft-ietf-dkim-rfc4871bis-09.txt
2011-04-28
08 (System) New version available: draft-ietf-dkim-rfc4871bis-08.txt
2011-04-24
07 (System) New version available: draft-ietf-dkim-rfc4871bis-07.txt
2011-04-12
06 (System) New version available: draft-ietf-dkim-rfc4871bis-06.txt
2011-03-28
05 (System) New version available: draft-ietf-dkim-rfc4871bis-05.txt
2011-03-28
04 (System) New version available: draft-ietf-dkim-rfc4871bis-04.txt
2011-02-16
03 (System) New version available: draft-ietf-dkim-rfc4871bis-03.txt
2010-10-11
02 (System) New version available: draft-ietf-dkim-rfc4871bis-02.txt
2010-09-27
01 (System) New version available: draft-ietf-dkim-rfc4871bis-01.txt
2010-08-16
00 (System) New version available: draft-ietf-dkim-rfc4871bis-00.txt