DomainKeys Identified Mail (DKIM) Signatures
draft-ietf-dkim-rfc4871bis-15
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
15 | (System) | post-migration administrative database adjustment to the Yes position for Pete Resnick |
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 |