Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
One final note from me, as I want to state my current position regarding 4871bis, with respect to Last Call. As the receiving verifier has all the information to _reliably_ [0] determine which combination(s) [1] of From [2] and DKIM-Signature verifies correctly, it has the means to provide any consuming application with the right information. The mechanism(s) by which the verification results can be communicated to a consumer (as per par. 6.2 of 4871bis) can be chosen by the verifier and does not restrict the results to only TEMPFAIL, PERMFAIL and SUCCESS [3]. Second, today there is hardly any installed base of MUA's that present any form of DKIM results to the end user, so most of this technology still needs to be written and 4871bis contains sufficient warnings about duplicate From and other fields; so in my view the argument of DKIM not being 'compatible' with the currently installed base of MUA's does not apply. Third, DKIM is only one of multiple technologies that can and will be deployed by both senders and receivers. This means that any policy published by a sender regarding the use of DKIM does not have to provide a sharp 'black' or 'white', 'keep' or 'discard' result. Senders that wish to publish a policy need to take into account that the world is not perfect and that there always will be lousy implementations of protocols (be it RFC5321, RFC5322, RFC4871 or RFC4871bis). [4] It's better to acknowledge this, than to rely on the 'MUST's in this particular DKIM RFC. Policies that do not take this into account, can/may have dramatic results. Hence, I no longer see a problem in 4871bis not mandating the duplicate header check. /rolf [0] irrespective of whether a From field has been prepended or appended or no such thing at all [1] (s) plural form, if there are multiple DKIM-Signatures and multiple From fields. [2] From is mentioned here only: - because it is the only mandatory header field to be used to generate the signature and - for the case that there's a consuming application that would display the From header, which in your view is the attack vector Apart from that, there is no special reason to focus here on From [3] although TEMPFAIL and PERMFAIL are mentioned in 4871, there is no equivalent identifier for a positive result, is there? I suggest to make the success status explicit in 4871bis [4] The fact that a sender doesn't know in advance how well the receiver implements the DKIM verification process will need to be taken into account for any policy protocol that will be built on top of DKIM. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
At 14:38 15-06-2011, The IESG wrote: The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' draft-ietf-dkim-rfc4871bis-12.txt 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 This document obsoletes RFC 4871 for which there is an IPR disclosure ( http://datatracker.ietf.org/ipr/1547/ ). As this is a move from Proposed to Draft, is a new IPR disclosure required? In Appendix B.1.4, n...@news-site.com could be changed to news@news-site.example (RFC 2606). In Section C.1: This differs from the usage in the original DKIM specification, where a null g= value is not valid for any address. I suggest a minor change, previous DKIM specification [RFC4871], for clarity. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
This document obsoletes RFC 4871 for which there is an IPR disclosure ( http://datatracker.ietf.org/ipr/1547/ ). As this is a move from Proposed to Draft, is a new IPR disclosure required? The disclosure you cite *is* the new one, which applies to the 4871bis draft (disclosure 1547 updates disclosure 920, which applied to RFC 4871 only). Yahoo! will update the disclosure again when 4871bis gets its own RFC number. Barry, DKIM working group chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
One final response from me to this, because it is relevant to the IETF last call: On Fri, Jun 24, 2011 at 1:33 PM, Douglas Otis do...@mail-abuse.org wrote: Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. No. We want to get the spec right, and to make sure it specifies the right normative things. Although DKIM will be securely hashing the headers fields which MUST include the From header, developers are being told they must ignore multiple singleton header fields discovered in the process. No one is saying that anyone must ignore anything. If you think we are, cite the words in the spec that say that. What we are saying, and have said repeatedly in many places, is that it is not the job of the DKIM specification to define the handling of this normatively. Developers may certainly handle the presence of multiple instances of header fields that are not allowed to have multiple instances... in any manner they like, and we even suggest (non-normatively) what they might do -- and ignoring the situation isn't among our suggestions. But it's not a normative part of the DKIM protocol, and it shouldn't be. Now I'm done responding to this topic. The points have all been made, on both sides. Barry, DKIM chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On 6/23/11 8:24 AM, John Levine wrote: In article4e02ee24.2060...@gmail.com you write: On 6/22/11 11:14 AM, Dave CROCKER wrote: Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. Dave is quite right. Doug's purported attack just describes one of the endless ways that a string of bytes could be not quite a valid 5322 message, which might display in some mail programs in ways that some people might consider misleading. If it's a problem at all, it's not a DKIM problem. Perhaps you can explain why the motivation stated in RFC4686 includes anti-phishing as DKIM's goal? Why of all the possible headers ONLY the From header field MUST be signed? Why RFC5617 describes the From header field as the Author Author address that is positively confirmed simply with a Valid DKIM signature result? Both RFC4686 and RFC5617 overlooked a rather obvious threat clearly demonstrated by Hector Santos on the DKIM mailing list: Pre-pended singleton header fields. Neither SMTP nor DKIM check for an invalid number of singleton header fields. These few header fields are limited to one because they are commonly displayed. Multiple occurrence of any of these headers is likely deceptive, especially in DKIM's case. DKIM always selects header fields from the bottom-up, but most sorting and displaying functions go top-down selection. Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? Although DKIM will be securely hashing the headers fields which MUST include the From header, developers are being told they must ignore multiple singleton header fields discovered in the process. It is not their burden! As if securely hashing, fetching any number of public keys, and verifying any number of signatures isn't? -Doug ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On Fri, Jun 24, 2011 at 12:33 PM, Douglas Otis do...@mail-abuse.org wrote: On 6/23/11 8:24 AM, John Levine wrote: In article4e02ee24.2060...@gmail.com you write: On 6/22/11 11:14 AM, Dave CROCKER wrote: Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. Dave is quite right. Doug's purported attack just describes one of the endless ways that a string of bytes could be not quite a valid 5322 message, which might display in some mail programs in ways that some people might consider misleading. If it's a problem at all, it's not a DKIM problem. Perhaps you can explain why the motivation stated in RFC4686 includes anti-phishing as DKIM's goal? Why of all the possible headers ONLY the From header field MUST be signed? Why RFC5617 describes the From header field as the Author Author address that is positively confirmed simply with a Valid DKIM signature result? Both RFC4686 and RFC5617 overlooked a rather obvious threat clearly demonstrated by Hector Santos on the DKIM mailing list: Pre-pended singleton header fields. Neither SMTP nor DKIM check for an invalid number of singleton header fields. These few header fields are limited to one because they are commonly displayed. Multiple occurrence of any of these headers is likely deceptive, especially in DKIM's case. DKIM always selects header fields from the bottom-up, but most sorting and displaying functions go top-down selection. Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? I'm not suffering from fatigue, personally, and I agree with their negative reaction toward your commentary. You're speaking as though you expect DKIM to be the *only* type of message validation that's going to happen to a message and thus it must account for and handle message flaws far outside of scope. This is like complaining that four wheels don't work as a car. True, but you're missing the point. And you're doing it in a manner so laden with hyperbole as to be offensive. It's really distressing and disrespecting to the rest of us to have to read your same complaint over and over and over. You've made your point. Few (none?) seem to agree. Could you please move on? Regards, Al Iverson ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On 6/24/2011 10:33 AM, Douglas Otis wrote: Complaints from John, Dave, and Barry and others is likely and understandably out of fatigue. They just want the process to be over. We are now hearing there is a vital protocol layering principle at stake which even precludes DKIM from making these checks! Really? For those who weren't paying attention, I thought it worth noting that Doug has now devolved into an ad hominem line of attack, complete with proffered insight into the personal motivations driving 3 of us, absent any external signs to support that insight. My own, actual, view is that a number of us have been considerably more than thorough in responding to Doug's entirely misguided campaign, within the DKIM working group, here on the IETF list, at the TrendLabs blog, at Circleid, and at the MAAWG Technical committee mailing list. The decision to stop responding to the substance of his postings is merely because there is no new substance. Absent any indication of his view gaining support, there's very obviously no benefit to be had in responding further. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On 6/22/11 11:14 AM, Dave CROCKER wrote: Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. A quick summary of the technical point at the core of Doug's concern is that the presence of multiple rfc5322.From header fields does appear to represent a plausible attack vector, but it also violates RFC5322 -- and RFC822, if anyone is worried about the history of this issue. DKIM (RFC4871) requires that the signing engine be handed a valid RFC5322 message. Hence the burden of ensuring that there is only one From: field rests outside DKIM. First, thank you for your response. I must ask however where do you see this burden being placed? If not on DKIM where? To clarify, the message format standard authored by you back in 1982 imposed no limit on the number of header fields and this was not revised until 2001. RFC822 Section 4.1 Syntax states: ,--- This specification permits multiple occurrences of most fields. Except as noted, their interpretation is not specified here, and their use is discouraged. '--- The current RFC4871bis only vaguely *recommends* compliance. 3.8. Input Requirements ,--- DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [RFC5322], [RFC2045], and any other relevant message format standards. '--- Another decade has passed and SMTP still fails to impose strict message format enforcement after limits were imposed on Orig-date, From, Sender, Reply-to, To, Cc, Message-id, In-reply-to, References, and Subject. Voicing opinions of protocol layering lends permission to DKIM implementers to also ignore these limits. :^( RFC5321 Section 3.3 states: ,-- When the RFC 822 format ([28], [4]) is being used, the mail data include the header fields such as those named Date, Subject, To, Cc, and From. Server SMTP systems SHOULD NOT reject messages based on perceived defects in the RFC 822 or MIME (RFC 2045 [21]) message header section or message body. '-- It is not reasonable to expect SMTP will impose necessary restrictions able to prevent deceptive DKIM results anytime in the near future. As the DKIM draft states, SMTP is not enforcing header limitations now. You expressed concern over protocol layers. What do you call the protocol layer you expect to be making these needed checks? Is this some highly opaque spam filter protocol layer? Will this layer guess whether DKIM checked RFC5322's header field requirements? If not guessing, how is this check being signaled? Those wishing to implement secure systems need to know whether a high value From header field might be mistakenly accepted based on signatures offered by some large free email provider. Free email providers often don't care whether header fields might be pre-pended when their reputation is based upon their volume. They are also unlikely to implement a wasteful fix of double listings of signed headers which then exposes high value domains to abuse well beyond their control. The DKIM specification claims it can be incrementally deployed. One might presume that acceptance might be based upon the signing domain. If not DKIM, what protocol layer ensures header field limitations have been imposed to prevent the signing domain's DKIM's assurances from becoming deceptive or evil? For reference, Doug posted a related blog recently and I posted a response yesterday: http://www.circleid.com/posts/searching_under_lampposts_with_dkim/ Others are posting responses also. The Comment mechanism, to the Circleid article, is being used to list these additional responses. Inline comments... On 6/21/2011 6:50 PM, Douglas Otis wrote:But, RFC4686 Introduction states: ... While several threats to DKIM were considered, multiple From header fields were neglected. This document only focused on use of multiple addresses within the From header field. Any possible omissions in an Informational threats document -- done 6 years ago and before the signing specification (RFC4871) was written -- is of marginal relevance, at best. Nevertheless, RFC4686 missed the threat created by multiple From header fields. It should be noted that Signing Practices are referenced off a domain found in the From header field which also assumes only one will be present. It also should be noted that Signing Practices (ADSP) issues are irrelevant to the candidate RFC4871bis effort, which pertains only to the signing specification. ADSP depends upon RFC4871's output where it is not possible to achieve the desired policies when pre-pended From header fields are ignored. This indicates the DKIM specification is seriously flawed. It indicates that there is an issue, not that it is DKIM's responsibility to solve it. What protocol do you expect will solve
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
In article 4e02ee24.2060...@gmail.com you write: On 6/22/11 11:14 AM, Dave CROCKER wrote: Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. Dave is quite right. Doug's purported attack just describes one of the endless ways that a string of bytes could be not quite a valid 5322 message, which might display in some mail programs in ways that some people might consider misleading. If it's a problem at all, it's not a DKIM problem. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Tuesday, June 21, 2011 6:51 PM To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner Subject: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard [...] This indicates the DKIM specification is seriously flawed. While DKIM may not offer author validation, it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. This purported security flaw and surrounding FUD was discussed at huge length in the working group, and consensus was clearly against the idea of dealing with this in DKIM because it's the wrong place to address the problem. The record, both in the issues tracker and in the working group's archive, is quite clear about this, and both are open to public scrutiny. And I find the tactic of taking a lost battle from a working group to the IETF as a whole to be akin to the Mom said no, I'll go ask Dad! strategy that I outgrew by the time I was a teenager... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
On Wednesday, June 22, 2011 01:17:16 pm Murray S. Kucherawy wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Tuesday, June 21, 2011 6:51 PM To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner Subject: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard [...] This indicates the DKIM specification is seriously flawed. While DKIM may not offer author validation, it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. This purported security flaw and surrounding FUD was discussed at huge length in the working group, and consensus was clearly against the idea of dealing with this in DKIM because it's the wrong place to address the problem. The record, both in the issues tracker and in the working group's archive, is quite clear about this, and both are open to public scrutiny. And I find the tactic of taking a lost battle from a working group to the IETF as a whole to be akin to the Mom said no, I'll go ask Dad! strategy that I outgrew by the time I was a teenager... While I'm not thrilled by the post-4871 changes in general, I think on this point there's not an issue. I recently worked through the multiple From case for a DKIM implementation I'm helping on and found sufficient guidance in RFC 4871 to deal with it reasonably. This was definitely beat to death in the WG. Scott K ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
Folks, The bottom line about Doug's note is that the working group extensively considered the basic issue of multiple From: header fields and Doug is raising nothing new about the topic. A quick summary of the technical point at the core of Doug's concern is that the presence of multiple rfc5322.From header fields does appear to represent a plausible attack vector, but it also violates RFC5322 -- and RFC822, if anyone is worried about the history of this issue. DKIM (RFC4871) requires that the signing engine be handed a valid RFC5322 message. Hence the burden of ensuring that there is only one From: field rests outside DKIM. For reference, Doug posted a related blog recently and I posted a response yesterday: http://www.circleid.com/posts/searching_under_lampposts_with_dkim/ Others are posting responses also. The Comment mechanism, to the Circleid article, is being used to list these additional responses. Inline comments... On 6/21/2011 6:50 PM, Douglas Otis wrote:But, RFC4686 Introduction states: ... While several threats to DKIM were considered, multiple From header fields were neglected. This document only focused on use of multiple addresses within the From header field. Any possible omissions in an Informational threats document -- done 6 years ago and before the signing specification (RFC4871) was written -- is of marginal relevance, at best. It should be noted that Signing Practices are referenced off a domain found in the From header field which also assumes only one will be present. It also should be noted that Signing Practices (ADSP) issues are irrelevant to the candidate RFC4871bis effort, which pertains only to the signing specification. This indicates the DKIM specification is seriously flawed. It indicates that there is an issue, not that it is DKIM's responsibility to solve it. While DKIM may notoffer author validation, Does not. Not may not. It's a simple and direct fact. it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. And it does that. But it does not make any assertions about the /validity/ of any of the data it signs, nevermind any of the data it does NOT sign. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. It actually has no discernible effect on DKIM's utility, nor have there been reports from the field of problems in 6 years of deployed use. Free email providers likely use DKIM to gain increased acceptance by taking advantage of their too big to block volumes. For these domains, their reputation is understood to offer little assurance of their overall integrity while perhaps limiting what is allowed in the domain portion of the From header field. This appears to be a political rant. By allowing a pre-pended From header field to not affect the validity of a DKIM signature according to the specification means the UNDERSTOOD source of a message can NEVER be trusted through the aid of DKIM. That statement well might be correct, but that's OK, since DKIM does not make assertions about source validity, except in terms of the separate DKIM signing identifier (in the DKIM-Signature: header field.) The signer is sometimes referred to as a source. However DKIM makes no assertions concerning the Author or Originator [RFC5598]. The general goal of DKIM cryptographically binding at a minimum the From header field of the message content to a domain was to act as a trust basis for acceptance. The general goal is to attach an identifier than is reliable and valid, and it does that. The identifier can be used for developing a reputation assessment of message streams signed with that identifier. DKIM also purports to allow incremental deployment without requiring additional undefined filtering be introduced in mail transfer or mail user agents. Clearly, the incremental deployment statement conflicts with the original goals due to the neglected input validation flaw. I have no idea what the above means. Details of this concern were stated in the tracker at: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 And it nicely shows that the working group considered the issue. This version of DKIM also introduced use of RFC5890 instead of RFC3490, which allows use of the German esset and the Greek final sigma, drops string-prep, and defines 3,329 invalid code points. Unfortunately, this version of the DKIM also failed to exclude use of Fake A-Labels, which when presented to the user may also prove highly deceptive. Excellent. Now it is also DKIM's job to fix problems with Unicode... Details of this concern were stated in the tracker at: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 wrong citation. d/ -- Dave Crocker Brandenburg
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
To add chair support to Murray's comment: On Wed, Jun 22, 2011 at 13:17, Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Douglas Otis Sent: Tuesday, June 21, 2011 6:51 PM To: ietf@ietf.org; Barry Leiba; iesg-secret...@ietf.org; Sean Turner Subject: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard [...] This indicates the DKIM specification is seriously flawed. While DKIM may not offer author validation, it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. This purported security flaw and surrounding FUD was discussed at huge length in the working group, and consensus was clearly against the idea of dealing with this in DKIM because it's the wrong place to address the problem. The record, both in the issues tracker and in the working group's archive, is quite clear about this, and both are open to public scrutiny. Indeed. We gave this issue at least two clear consensus calls, and it's very clear that the rough consensus considers the kind of validation that Doug is asking for to be a good idea, but outside the scope of the DKIM protocol. That is, the validation ought to be done in another part of the software system. The document does actually advise that, and that advice is all that working group consensus was behind. Consensus also is that Doug is severely overstating the problem. This has been decided and re-decided. And I find the tactic of taking a lost battle from a working group to the IETF as a whole to be akin to the Mom said no, I'll go ask Dad! strategy that I outgrew by the time I was a teenager... I, too, have a problem with how IETF last call is sometimes being used by working group participants to rehash issues. But that's a subject for a separate conversation, and not for here. Barry, DKIM working group chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
Background on preceding DKIM work-- RFC4686 Introduction states: ,--- The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. '--- While several threats to DKIM were considered, multiple From header fields were neglected. This document only focused on use of multiple addresses within the From header field. RFC5585 Introduction states: ,--- DKIM allows an organization to take responsibility for a message in a way that can be verified by a recipient. [..] It permits verification of the signer of a message, as well as the integrity of its contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments of unsigned messages. DKIM's authentication of email identity can assist in the global control of spam and phishing. '--- It should be noted that Signing Practices are referenced off a domain found in the From header field which also assumes only one will be present. RFC2119 definition ,--- SHOULD This word, or the adjective RECOMMENDED, mean that there may exist _valid_ reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. '___ Section 3.8 Input Requirements states that verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to RFC5322, RFC2045, and any other relevant message format standard. Section 8.14 Attacks Involving Addition of Header Fields acknowledges: ,--- Many email implementations do not enforce [RFC5322] with strictness as discussed in Section 5.3 (Normalize the Message to Prevent Transport Conversions), DKIM processing is predicated on a valid mail message as its input. However, DKIM implementers should be aware of the potential effect of having loose enforcement by email components interacting with DKIM modules. '___ and further states: ,--- An MUA then might elect to render to the user the value of the first, or top, From: field. This may also be done simply out of the expectation that there is only one, where a find first algorithm would have the same result. Such code in an MUA can be exploited to fool the user if it is also known that the other From: field is the one checked by arriving message filters. Such is the case with DKIM; although the From: field must be signed, a malformed message bearing more than one From: field might only have the first (bottom) one signed, in an attempt to show the message with some DKIM passed annotation while also rendering the From: field that was not authenticated. (This can also be taken as a demonstration that DKIM is not designed to support author validation.) '___ This indicates the DKIM specification is seriously flawed. While DKIM may not offer author validation, it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. Free email providers likely use DKIM to gain increased acceptance by taking advantage of their too big to block volumes. For these domains, their reputation is understood to offer little assurance of their overall integrity while perhaps limiting what is allowed in the domain portion of the From header field. By allowing a pre-pended From header field to not affect the validity of a DKIM signature according to the specification means the UNDERSTOOD source of a message can NEVER be trusted through the aid of DKIM. Those that phish by taking advantage of this neglected flaw are unlikely to affect the acceptance of any exploited high volume domain. DKIM could have avoided offering false assurances by not ignoring illegal multiple header fields per RFC5322 and defining such messages as resulting in invalid signatures. Unfortunately, when essential input checks are skipped, acceptance based upon DKIM's now potentially deceptive results may play an evil role that cannot be repaired through the use of reputation. The general goal of DKIM cryptographically binding at a minimum the From header field of the message content to a domain was to act as a trust basis for acceptance. DKIM also purports to allow incremental deployment without requiring additional undefined filtering be introduced in mail transfer or mail user agents. Clearly, the incremental deployment statement conflicts with the original goals due to the neglected input validation flaw. Details of this concern were stated in the tracker at: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 This
Re: Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
In article 20110615213858.9853.22165.idtrac...@ietfa.amsl.com you write: The IESG has received a request from the Domain Keys Identified Mail WG (dkim) to consider the following document: - 'DomainKeys Identified Mail (DKIM) Signatures' draft-ietf-dkim-rfc4871bis-12.txt as a Draft Standard I've reviewed this document, indeed my fingerprints are all over it. It's definitely an improvement to 4871: folds in the errata, takes out a lot of gratuitous and often wrong non-normative advice, cleans up the 2119 MUSTage, and otherwise improves the text. Except for the one obscure feature that is deprecated due to lack of use, I think that any implementation that is compliant with 4871+errata should still be compliant with this draft. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dkim-rfc4871bis-12.txt (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' draft-ietf-dkim-rfc4871bis-12.txt 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 i...@ietf.org mailing lists by 2011-06-29. Exceptionally, comments may be sent to i...@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/ ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
