Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack, why RFC 5322 compliance is a fuzzy term, and what about malformed MIME str
Murray S. Kucherawy wrote: It boggles my mind that a specification called DomainKeys Identified _MAIL_ has to be explicit about the fact that the input is expected to be formatted like a mail message, and that there's even pressure to say in a normative way that someone implementing this has to make sure that's the case. Security Considerations of RFC5451 was updated to include language about hardening against input deliberately crafted to try to confuse or crash applications, and I was surprised that they (secdir) felt that was necessary; I expected that to be fairly obvious to anyone in the audience of a standards track RFC. (It wasn't required to be normative, however.) In my view of the IETF RFC documents, its a matter of technical writing style. They are neither a 100% Functional Specification nor 100% Technical Specification, but a blend to help reach a wider audience of disciplines. A good amount of expertise and/or experience is required to get the message across and it also requires a good amount of expertise/experience to be able to read the message to both a) extract and b) extend the engineering insights required to produce the protocol. In this case, in my technical opinion, Section 5.4 has incomplete implementation insights regarding the single field requirements for RFC 5322. It is an insight that would of been included if we had seen the issue when it was first written four years ago, especially when we went through the TA process. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack, why RFC 5322 compliance is a fuzzy term, and what about malformed MIME str
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Thursday, November 04, 2010 12:09 PM To: ietf-dkim@mipassoc.org Subject: [...] Uh, ok, you're right. I guess I should have stopped arguing since this thread became a dialogue among deaf people --I would have done so if I had seen any other sign of progress on this subject. BTW, I haven't yet tried to submit that EXE file to the DKIM software I use. I will. I hope we all agree that the spec's better not contain phrases such as an implementation SHOULD crash... :-/ It boggles my mind that a specification called DomainKeys Identified _MAIL_ has to be explicit about the fact that the input is expected to be formatted like a mail message, and that there's even pressure to say in a normative way that someone implementing this has to make sure that's the case. Security Considerations of RFC5451 was updated to include language about hardening against input deliberately crafted to try to confuse or crash applications, and I was surprised that they (secdir) felt that was necessary; I expected that to be fairly obvious to anyone in the audience of a standards track RFC. (It wasn't required to be normative, however.) ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Tue, 02 Nov 2010 18:47:23 -, Alessandro Vesely ves...@tana.it wrote: On 01/Nov/10 22:56, Douglas Otis wrote: On 10/30/10 3:05 AM, Alessandro Vesely wrote: On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. [...] ADSP compliance only requires a valid DKIM signature by the Author Domain, as currently defined by DKIM. This does not protect against pre-pended singleton header fields containing a domain that may have a restricted ADSP assertion, even one that always signs with multiple singleton header fields listed in the h= parameter. If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. ... But in Doug's example, the verifier (following the letter of RFC4871) will report only that it saw a valid signature from the domain big-isp.com. It will not report anything at all (either good or bad) about big-bank.com since (followng 4871) it was not signed. That is the 4871 hole we are tying to fix. ... Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. No, that wording applies to multiple addresses in a single From header. If there are two From headers, ADSP has nothing to say on which to use, so the expectation is that its implementations will use the first, when asked to to an ADSP lookup. The whole point of this scam is that big-isp.com (the Bad Guy in this case) wants to prevent that lookup from ever happening. As the two specs (DKIM and ADSP) are currently written, his scam will succeed. Even if we fixed the ADSP spec (which is not on our current agenda), existing ADSP implementations would still get caught. SO we MUST fix it in DKIM, which IS on our agenda. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Yes it is ugly but, worse, it does not prevent this particular scam. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Big-isp.com is the Bad Guy here. His poor signing practices are quite deliberate. Which is why only a header-counting verifier can catch him. -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: ...@clerew.man.ac.uk snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
On 02/Nov/10 22:58, Douglas Otis wrote: On 11/2/10 11:47 AM, Alessandro Vesely wrote: On 01/Nov/10 22:56, Douglas Otis wrote: If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Per RFC5322 Section 3.6.2, the From header field may contain a comma separated list of mailbox specifications. Section 3 of RFC5617 does not indicate how multiple From header fields are to be handled. This refers to multiple Author Addresses which may exist within a single From header field. Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. 50% agreed. This mistake is only in DKIM, IMHO. There remains uncertainty as to which From header field might be selected whenever multiple singleton header fields exist. The uncertainty is not resolved by Section 3 of RFC5617, which again presumes RFC5322 compliance. When there is a conflict in DKIM's bottom-up selection process and a typical display or sorting process using top-down, the presumption of RFC5322 compliance creates an easily exploited DKIM security gap! RFC 5616 actually just says multiple Author Addresses. It does not say that having examined a single From field is sufficient. Although, that is an apparently legitimate inference --if one assumes RFC 5322 compliance-- software that acts that way can still be considered buggy. Multiple listings of singleton header fields in the h= parameter This hack does not address the security concern! It incorrectly presumes the valid signature being exploited is that of a high value domain attempting to protect their recipients from a spoofing attack. It does not presume that. The hack just allows signers to protect from this exploit /if they care/. In order to protect against illicit usage of a domain name by third parties one could use ADSP. The valid signature could easily be that of a large domain that is unlikely blocked. Only proactive policies are able to preclude highly polymorphic botnet attacks. Blocking based upon reputation will not be effective in the case of large domains, or in the case of new domains. You mean the receiving host has a whitelist_from_dkim clause? Yes, in that case the message probably passes even if it fails ADSP. How is this a DKIM error? It has been repeatedly noted that DKIM allows producing poor signatures, and whitelisting signers with such practices is a questionable setting. Nevertheless, it works. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Disagree. DKIM verification failed to ensure the presumption of RFC5322 singleton header field compliance. As such, ADSP compliance could be based upon an unseen DKIM signature and an unseen From header field. Here you hypothesize that the ADSP verifier is unable to see all the From fields in the message. That makes this an implementation issue. Tough verifiers see all author addresses. It would not matter whether high-value domains always include multiple singleton header fields in their h= parameter! Since other domains are unlikely affected by From header field spoofing, why require a practice for every other large domain to use this ugly, wasteful, and ineffective hack? Because it protects from this specific attack. A domain does not set h=from:from to protect against abuse of its domain name: It sets it in order to protect its signatures from being spoofed. Admitting a mistake and including explicit checks for multiple singleton header fields in the DKIM verification process properly handles the greater concern. This proper repair will reduce multiple listings of singleton header fields to being an interim solution for an unlikely exploit. IMHO, it is not the proper solution. It changes the design of DKIM so as to include heuristic considerations about RFC 5322 compliance that are not pristine to digital signatures. That would result in fuzzy results and more false positives. I note that the 95% pass shown in http://www.opendkim.org/stats/report.html#mlm_comparison is so low that nobody would discard a message because of an invalid signature. For DKIM to be usable, we should reduce that 5% failure rate, rather than increase it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. 50% agreed. This mistake is only in DKIM, IMHO. At this point, it would be helpful if you could propose specific language for 4871bis. And if it's not presuming 5322 compliance, it would also be helpful if you could say in detail what a DKIM signer and verifier should do if presented with, say, a Windows executable file. Not a MIME encoded message body containing one, just an EXE file. If you don't require 5322 compliance or something close to it, that's as legitimate a signing candidate as anything. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
On 11/3/10 6:28 AM, Alessandro Vesely wrote: On 02/Nov/10 22:58, Douglas Otis wrote: On 11/2/10 11:47 AM, Alessandro Vesely wrote: If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Per RFC5322 Section 3.6.2, the From header field may contain a comma separated list of mailbox specifications. Section 3 of RFC5617 does not indicate how multiple From header fields are to be handled. This refers to multiple Author Addresses which may exist within a single From header field. Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. 50% agreed. This mistake is only in DKIM, IMHO. We're in agreement. When fixed in DKIM, it would not be needed for ADSP. There remains uncertainty as to which From header field might be selected whenever multiple singleton header fields exist. The uncertainty is not resolved by Section 3 of RFC5617, which again presumes RFC5322 compliance. When there is a conflict in DKIM's bottom-up selection process and a typical display or sorting process using top-down, the presumption of RFC5322 compliance creates an easily exploited DKIM security gap! RFC 5616 actually just says multiple Author Addresses. It does not say that having examined a single From field is sufficient. Although, that is an apparently legitimate inference --if one assumes RFC 5322 compliance-- software that acts that way can still be considered buggy. This includes specifications lacking confirmations needed to avoid selection error exploits. Multiple listings of singleton header fields in the h= parameter This hack does not address the security concern! It incorrectly presumes the valid signature being exploited is that of a high value domain attempting to protect their recipients from a spoofing attack. It does not presume that. The hack just allows signers to protect from this exploit /if they care/. In order to protect against illicit usage of a domain name by third parties one could use ADSP. From: accou...@big-bank.com (pre-pended by bad actor) From: some...@big-isp.com DKIM-Signature: d=big-isp.com; h=from; ... misleading body content when related with accou...@big-bank.com Current DKIM specifications allow messages with pre-pended singleton headers to receive valid Author Domain Signature status. As such, ADSP might not offer any additional protection, since DKIM header stack selection is normally bottom-up. However, displaying or sorting might select accou...@big-bank.com instead of some...@big-isp.com when header stack selection by these processes is top-down. It does not matter how big-bank.com normally signs their messages! Big-bank.com is unable to prevent the exploit that uses big-isp.com, even by using ADSP with a discardable assertion! Their recipients may accept spoofing attempts based upon erroneous DKIM PASS status. These recipients may then draw incorrect conclusions based upon this erroneous DKIM PASS status. The valid signature could easily be that of a large domain that is unlikely blocked. Only proactive policies are able to preclude highly polymorphic botnet attacks. Blocking based upon reputation will not be effective in the case of large domains, or in the case of new domains. You mean the receiving host has a whitelist_from_dkim clause? Yes, in that case the message probably passes even if it fails ADSP. How is this a DKIM error? It has been repeatedly noted that DKIM allows producing poor signatures, and whitelisting signers with such practices is a questionable setting. Nevertheless, it works. No. You have incorrectly concluded big-bank.com controls the signature being exploited. A bad actor can exploit signatures of big-isp.com to deceive recipients who might see From: accou...@big-bank.com. This exploits the likely acceptance of big-isp.com's message stream, and perhaps any added general status annotations. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Disagree. DKIM verification failed to ensure the presumption of RFC5322 singleton header field compliance. As such, ADSP compliance could be based upon an unseen DKIM signature and an unseen From header field. Here you hypothesize that the ADSP verifier is unable to see all the From fields in the message. That makes this an implementation issue. Tough verifiers see all author addresses. ADSP depends upon DKIM PASS status. However, DKIM failed to require the needed checks against possible
Re: [ietf-dkim] Proposal for new text about multiple header issues
... Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. No, that wording applies to multiple addresses in a single From header. If there are two From headers, ADSP has nothing to say on which to use, so the expectation is that its implementations will use the first, when asked to to an ADSP lookup. The whole point of this scam is that big-isp.com (the Bad Guy in this case) wants to prevent that lookup from ever happening. As the two specs (DKIM and ADSP) are currently written, his scam will succeed. Charles, It should be noted that this single 5322.From header with multiple address values scenario was discussed at length in the past with the original SSP draft and the consensus was that SSP checkers should use the first address domain. From the August 2006, SSP draft rev02 draft, section 2.3: http://tools.ietf.org/id/draft-allman-dkim-ssp-02.txt 2.3. Originator Address The Originator Address is the email address in the From header field of a message [RFC2822], or if and only if the From header field contains multiple addresses, the first address in the From header field. NON-NORMATIVE RATIONALE: The alternative option when there are multiple addresses in the From header field is to use the value of the Sender header field. This would be closer to the semantics indicated in [RFC2822] than using the first address in the From header field. However, the large number of deployed Mail User Agents that do not display the Sender header field value argues against that. Multiple addresses in the From header field are rare in real life. As noted that this very rare, to cover all security angles regarding a possible domain order relationship of the addresses, IMO, ADSP is technical correct in stating it SHOULD check each domain value. I seem to recall citing a method that can help decide the order of checking the domains using the sender or the signer domain. If the signer domain matches any of the single 5322.from header with multiple domains, it might consider checking this domain policy first with the idea the 1st party signature is more important (trust wise) than a 3rd party domain. It can also use logic to compare the Sender. For example: Sender: t...@domain3.com From: b...@domain1.com, t...@domain3.com, j...@domain2.com, sa...@domain4.com DKIM-Signature: d=domain2.com There is reasonable logic here to suggest the domain policy lookup order might be: domain2.com - check for 1st party policy domain3.com - check for a Sender policy domain1.com - check remaining in order presented domain4.com existing ADSP implementations would still get caught. SO we MUST fix it in DKIM, which IS on our agenda. Technically, in the name of protocol consistency, if there is no DKIM signature, POLICY is still part of the handling framework. This was highlighted in the Threats Analysis (TA) RFC4686 and the SSP Functional Requirements RFC5016 in how it related to failed signature and also 1st party versus 3rd party signatures. Overall, if there was probably one absolute majority consensus among all sides of the policy question, was the solid TA recognition that a valid 1st party signature was a solid reason to short-circuit (skip) a policy lookup. This is codified in RFC5016 section 5.3 item #9: 9. SSP MUST NOT be required to be invoked if a valid first party signature is found. So policy is still active when there is no valid signature. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Yes it is ugly but, worse, it does not prevent this particular scam. I don't particular like the kludge, but that should not mean it could not be mentioned as part of the specification as a possible feature DKIM API writers or implementors to consider to cover all bases. In other words, the functional spec (ideally) should just mention all the known possible methods software engineers can consider to mitigate the potential exploit. 1 - Integrate DKIM with mail system components that can perform RFC5322 compliance checking with a focus on multiple 5322.From violations. Note: As a new general consideration, all MTA/MUA developers should consider implementing this multiple 5322.From checking, if not done already, as a general practice. 2 - Include specific RFC5322 checking for items that are related to the DKIM verification or signing process. i.e. check for multiple 5322.From headers. 3 - Consider a multiple h=from:from...[:from] N from values to force invalid signatures when N+1 5322.From headers are found.
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 01/Nov/10 22:56, Douglas Otis wrote: On 10/30/10 3:05 AM, Alessandro Vesely wrote: On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. [...] ADSP compliance only requires a valid DKIM signature by the Author Domain, as currently defined by DKIM. This does not protect against pre-pended singleton header fields containing a domain that may have a restricted ADSP assertion, even one that always signs with multiple singleton header fields listed in the h= parameter. If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Why ugly hack? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. For the only by part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues (why multiple h= singleton listing is an ineffective hack.)
On 11/2/10 11:47 AM, Alessandro Vesely wrote: On 01/Nov/10 22:56, Douglas Otis wrote: If big-bank.com asserts a restrictive policy, the relevant author address should make that message fail ADSP verification, since no author domain signature can be found. Apparently, RFC 5617 already provides for multiple author addresses. Section 3 reads If a message has multiple Author Addresses, the ADSP lookups SHOULD be performed independently on each address. Per RFC5322 Section 3.6.2, the From header field may contain a comma separated list of mailbox specifications. Section 3 of RFC5617 does not indicate how multiple From header fields are to be handled. This refers to multiple Author Addresses which may exist within a single From header field. Presumption of RFC5322 compliance is the mistake made in DKIM and ADSP. There remains uncertainty as to which From header field might be selected whenever multiple singleton header fields exist. The uncertainty is not resolved by Section 3 of RFC5617, which again presumes RFC5322 compliance. When there is a conflict in DKIM's bottom-up selection process and a typical display or sorting process using top-down, the presumption of RFC5322 compliance creates an easily exploited DKIM security gap! Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Why ugly hack? You mean from an aesthetic POV? Yes, some bytes are wasted, as usual. Whenever we'll recycle we should fix that. (MIME compliance and UTF-8 header would be valid reasons for v=2, IMHO.) Since it addresses precisely this issue, it is not incomplete in that respect. This hack does not address the security concern! It incorrectly presumes the valid signature being exploited is that of a high value domain attempting to protect their recipients from a spoofing attack. The valid signature could easily be that of a large domain that is unlikely blocked. Only proactive policies are able to preclude highly polymorphic botnet attacks. Blocking based upon reputation will not be effective in the case of large domains, or in the case of new domains. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. If ADSP verification is thorough, the exploit can only succeed when big-bank.com asserts no restrictive ADSP. In such case, yes, the exemplified message may verify. Blame poor signing practices at big-isp.com. Disagree. DKIM verification failed to ensure the presumption of RFC5322 singleton header field compliance. As such, ADSP compliance could be based upon an unseen DKIM signature and an unseen From header field. It would not matter whether high-value domains always include multiple singleton header fields in their h= parameter! Since other domains are unlikely affected by From header field spoofing, why require a practice for every other large domain to use this ugly, wasteful, and ineffective hack? Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. Not quite. Big-isp.com may delegate responsibility for the From field to the relevant author, as it seems common practice. Then, one doesn't even need to infringe RFC 5322 to produce a DKIM-valid bait. Only by ensuring valid DKIM signatures included a check that there is no multiple singleton header fields, will valid DKIM signature exploitation be mitigated! Only then would deceptive messages be blocked by restrictive ADSP assertions. Currently, one must hope that big-isp.com will not sign a message containing multiple singleton header fields. Even DKIM verification failed to explicitly require there be no multiple singleton header fields before DKIM signatures are considered valid. For the only by part, unaesthetic signing practices _can_ avoid the singleton exploit. If big-isp.com carefully validates the From field, it should also include it twice in the h= tag. Possibly, one might even derive from there a criterion for guessing what kind of signing practices have been applied. Having the h= parameter list multiple singleton header fields will not mitigate the exploit when signed by _different_ domains that have _different_ h= parameters and ADSP assertions. Once there are checks
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/30/10 3:05 AM, Alessandro Vesely wrote: On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. Sorting or display selection exploits can occur whenever handling is based upon valid DKIM signatures by trusted domains. By not confirming singleton header fields have not pre-pended an existing header field, especially a From header field, this creates an exploit exposure. DKIM normally uses a bottom-up selection process that mistakenly presumed RFC5322 compliance. Avoiding exploitation of a valid DKIM signature MUST ensure against pre-pended singleton header fields, since most subsequent processing will use top-down header field selections. ADSP compliance only requires a valid DKIM signature by the Author Domain, as currently defined by DKIM. This does not protect against pre-pended singleton header fields containing a domain that may have a restricted ADSP assertion, even one that always signs with multiple singleton header fields listed in the h= parameter. Multiple listings of singleton header fields in the h= parameter is an ugly and wasteful hack that offers an incomplete remedy for these selection conflicts. Note: RFC5322 defines the following singleton header fields: orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, and subject. In the example, a domain being targeted by attacks may assert ADSP discardable and sign with the h= parameter listing multiple singleton header fields. A victim might accept information based upon a valid DKIM signature, only to then be misled by different selections used by the display or sort process. DKIM fails to mitigate the exploitation of a DKIM signature inappropriately considered valid when multiple singleton header fields exist. Only by ensuring DKIM never asserts a valid signature for messages having multiple singleton header fields, can exploitation of a valid DKIM signature status be avoided. It is not reasonable to presume the transport will exclude these messages. Ensuring against a valid DKIM result when there are multiple singleton header fields is not the same as enforcing RFC5322 compliance. This only ensures against DKIM's mistaken presumption of RFC5322 compliance. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 28/Oct/10 03:36, Douglas Otis wrote: I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Besides RFC 5322 compliance, how is this different from a traditional unsigned spoofed From: accou...@big-bank.com? Having just a signature doesn't mean much, and spelling how to match signature and From field is ADSP's job, even in corner cases. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 25/Oct/10 06:54, Steve Atkins wrote: On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote: 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. Implementations, e.g. OpenDKIM, may be configured with a list of fields-to-sign, rather than the exact content of the h= tag. Thus, such a signer can double the occurrence of singleton fields as part of DKIM-Signature creation. Or it can slightly improve its configuration grammar in order to let the user specify when fields are to be bounded by adding an extra instance of their name in the h= tag. We can sprinkle any amount of syntactic sugar on that... I think that, although it may seem simpler to deal with the problem at the receiver's, we've seen it actually is not simpler at all. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem. Why it's not ideal? Even having to specify From may be felt as a nuisance, since it's mandatory already. Kay Engert's serendipitous reinvention of DKIM, http://kuix.de/spamsalt/, provides for a fixed set of signed header fields: does that make spamsalt less hacky than DKIM? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/27/10 8:53 PM, Hector Santos wrote: The lack of focus for 1st party domain protection is what allowed this issue to fall through the crack. We tried our best to make DKIM a pure signing mechanism with an open ended implicit policy of unrestricted resigners, remolding the specs with out of scope wink wink design goals. MLM allowance or tolerance became a dominant goal over the principle benefit DKIM can provide - 1st party DOMAIN protection. The solution is an integrated solution. DKIM itself can not solve this. At this point, what's missing are HANDLING provisions for DKIM verifiers. A real POLICY protocol with 3rd party considerations is really the only thing that can help resolve this problem. Even Reputation Vendors can help here but they need to support POLICY too. Instead, the pressure has been to eliminate it. Agreed. But additional handling provisions are meaningless without DKIM PASS offering an actionable state. Unless trivial exploits allowed by multiple (singular) header fields are assured to receive PERMFAIL, DKIM will not offer a basis for message handling or annotation. There is ongoing effort within the TPA-Label scheme. Several companies also want an authorized third-party reporting mechanism as well, which can be combined with the TPA-Label extensions. Third-party information needs to be made generally available before such policy assertions become easy for typical administrators. The difficult policy issues involve multiple domains when seeking meaningful and concise handling decisions without disrupting legitimate message sources. The relatively small number of legitimate sources makes this a tractable problem, especially for those who track these sources. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/10 9:36 PM, Murray S. Kucherawy wrote: On Monday, October 25, 2010 2:48 PM, Douglas Otis wrote: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. Bad advice. There is no other email component that can be relied upon to restore flawed DKIM verification results, nor should DKIM relegate determination of DKIM result validity to subsequent consumers. But neither of those was the suggestion. A DKIM Signature Verification returning PASS when there are multiple From header fields provides information that REQUIRES additional checks before it can be safely employed by _any_ consumer of DKIM results. In nearly every case, such a message is the result of a bad actor attempting to exploit the lack of essential conformance checks. Subsequent checking of DKIM results represents a clear protocol layer violation, where this checking SHOULD be done by DKIM. Suggesting that omitting these checks is okay represents Bad Advice. The DKIM protocol MUST require checks that are critical to the safe use of DKIM results, and not simply document the mistaken omission of these checks that implies subsequent consumers of DKIM results are expected to make these checks instead, or expected to have a header selection process of what should be a singular header field conform with DKIM's bottom-up processing. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the h= portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). Incomplete advice. This only provides partial protection, since it does not prevent spoofing of a From header where an attacker controls or utilizes a domain that does not include repeated From header entries within the h= parameter. I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Reputation can not fix this problem. Fobbing this onto the consumers of DKIM results goes against the goal of increasing trust in email, and against the spirit of doing our best at providing accurate results. Let's fix our mistake. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
Douglas Otis wrote: I'm having trouble parsing that. Please propose alternate text, or show an example of what you're describing. I'll repeat the example given previously. The multiple listing of a header in the h= parameter can not mitigate exploitation of DKIM PASS results where a valuable domain is prefixed to that of large domain. The large domain is unlikely concerned by possible presence of a pre-pended header field, where their decision not to include multiple listing for a message clearly not compliant with RFC5322. In other words, this leaves DKIM results open to exploitation. From: accou...@big-bank.com From: some...@big-isp.com DKIM-Signature: h=from, d=big-isp.com, ... Reputation can not fix this problem. Fobbing this onto the consumers of DKIM results goes against the goal of increasing trust in email, and against the spirit of doing our best at providing accurate results. Let's fix our mistake. The lack of focus for 1st party domain protection is what allowed this issue to fall through the crack. We tried our best to make DKIM a pure signing mechanism with an open ended implicit policy of unrestricted resigners, remolding the specs with out of scope wink wink design goals. MLM allowance or tolerance became a dominant goal over the principle benefit DKIM can provide - 1st party DOMAIN protection. The solution is an integrated solution. DKIM itself can not solve this. At this point, what's missing are HANDLING provisions for DKIM verifiers. A real POLICY protocol with 3rd party considerations is really the only thing that can help resolve this problem. Even Reputation Vendors can help here but they need to support POLICY too. Instead, the pressure has been to eliminate it. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
--On 25 October 2010 09:55:47 -0700 Steve Atkins st...@wordtothewise.com wrote: 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, such as From or Subject, to an already signed message in a way that doesn't break the signature. The resulting message violates section 3.6 of [MAIL] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. My guess is that for the set of MUAs that aren't paying attention to DKIM signatures, random placement of the second header will ensure that the wrong header is displayed 50% of the time. Familiarity with a few popular MUAs (assuming that they deterministically display either the first or the last) would achieve better than 50% display rates. Heck, if you insert one header before the signed header, and one after, then you might well get a 100% display rate across all MUAs that aren't aware of this problem. It's conceivable that unpredictable is Because of this, inbound mail system implementors should consider defending against this sort of replay attack by either 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). And, Date, please? It also meets those criteria. Some messages might have quite different meanings when the date is changed. Perhaps a message with instructions to call a premium rate phone number, by Friday. Such a message might be repurposed after the number has changed hands. Or, a political statement might have very different implications at a later date. For example, I saw a tweet recently saying that a UK coalition government minister (a Liberal Democrat) had called another government minister (a Conservative) incompetent. It turned out that this was true, but the linked article was written months before the recent general election, before the coalition was formed. So, the implications were very different than if the statement were made today. 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. Senders who feel that their messages might be particularly vulnerable to this sort of attack who don't want to rely on receiver filtering of invalid messages can ensure that adding additional headers will break their DKIM signature by including two copies of the headers they're concerned about in the signature (e.g. h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further discussion. h= ... from:from:to:to:subject:subject:date:date ... -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. Well, actually, if you read 4871, it also produces an edited version of the message. As I suggested in my message a few days ago, I don't think that's what we intended, and we should fix 4871bis so it doesn't say that any more. And that makes DKIM overall a poor place to do anything other than mention specific issues that directly affect the DKIM security model. Agreed. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
The thought is that two Subject lines is worth rejecting, an extra at sign in the Message-ID is not. I'm fine with that if we think implementers will find it easier to construct a comprehensive likely list versus just enforcing the spec. It's not easier but I'm with Steve here. People are not likely to implement a spec that says that verifiers fail due to trivial syntax errors in the message. At this point, the only things I'm aware of that present a risk of bad rendering are duplicate headers and l= that doesn't cover the whole message. That list may grow in the future, but I doubt it will grow very fast. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/2010 7:47 AM, John Levine wrote: A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. Well, actually, if you read 4871, it also produces an edited version of the message. Please cite the text in the specification that defines this output process and/or result. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
--On 24 October 2010 22:10:34 -0700 Steve Atkins st...@wordtothewise.com wrote: A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. Actually, my verifier produces two bits: one for the headers, and one for the body. In terms of authentication, that might not mean much. It is useful for debugging, though. It also says if the public key was unavailable, or contained a syntax error: For what it's worth, today, on one cluster, I see these counts: 12 invalid - public key record (currently?) unavailable 19 invalid - syntax error in public key record 31 verification failed - body hash mismatch (body probably modified in transit) 285 verification failed - signature did not verify (headers probably modified in transit) 1776 verification succeeded -- Ian Eiloart IT Services, University of Sussex 01273-873148 x3148 For new support requests, see http://www.sussex.ac.uk/its/help/ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/2010 8:16 AM, Ian Eiloart wrote: Actually, my verifier produces two bits: one for the headers, and one for the body. In terms of authentication, that might not mean much. It is useful for debugging, though. We need to be careful to distinguish between software and protocol. Software is free to do whatever it wants. The DKIM Signing specification, however, deals with constrained, standardized behavior. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 10:50 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Sunday, October 24, 2010 10:36 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues That still expands the API from the DKIM verifier quite a lot - it requires the verifier to explicitly list which headers are signed, and which aren't (that the h= field doesn't do that is what we're having problems with). It would also require that to be pushed all the way downstream to other pieces of software, perhaps via something similar to an extended Authentication-Results type of header. That's not impossible, but seems very complex for the specific problem we're considering - we just need to communicate This message violated 5322, specifically in a way that makes us think the sender is trying to game DKIM (either by flagging the mail as syntactically invalid and suspicious at some point in the mail stream, or invalidating the DKIM signature). [...] You seem to have some specific ideas in mind already. Can you propose some alternate text? Sure. Taking into account some of the other feedback too: --- 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, such as From or Subject, to an already signed message in a way that doesn't break the signature. The resulting message violates section 3.6 of [MAIL] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Because of this, inbound mail system implementors should consider defending against this sort of replay attack by either 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. Senders who feel that their messages might be particularly vulnerable to this sort of attack who don't want to rely on receiver filtering of invalid messages can ensure that adding additional headers will break their DKIM signature by including two copies of the headers they're concerned about in the signature (e.g. h= ... from:from:to:to:subject:subject ...). See section 3.5 and 5.4 for further discussion. --- It's significantly less subtle than your phrasing, but I think bluntness and clarity win out for a security discussion. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Monday, October 25, 2010 9:56 AM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, such as From or Subject, to an already signed message in a way that doesn't break the signature. I'd strike during a replay attack because, as some have noted, the attack can be constructed deliberately on an original message. I'd also probably want to include some of my original text that sets up why various agents are so permissive today. The resulting message violates section 3.6 of [MAIL] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. It's also not specific to MUAs. Filtering agents can be similarly duped. 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. These almost say the same thing to me. For example, treat as unsigned could be rolled into treat as suspicious. And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME. If you concur, I'll take another run at it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 12:19 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Monday, October 25, 2010 9:56 AM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 8.14 Malformed Inputs DKIM allows additional headers to be added to a signed message without breaking the signature. This tolerance can be abused during a replay attack by adding additional copies of headers that are displayed to the end user, such as From or Subject, to an already signed message in a way that doesn't break the signature. I'd strike during a replay attack because, as some have noted, the attack can be constructed deliberately on an original message. The real risk here is that someone can present a message as signed by someone trustworthy that has content different to that which was provided by the trusted signer. If the entity adding the additional content is the original signer, it may be a message composition bug, but it's not really any sort of attack on DKIM. Striking replay attack might make it less clear what the actual risk is, rather than more clear. (... can be abused, e.g. during a replay attack, by adding ... ?) I'd also probably want to include some of my original text that sets up why various agents are so permissive today. I'm not sure the history adds anything, and briefer tends to lead to a clearer call to action. (And it annoys Mark, and may be continuing a misinterpretation of the robustness principle and...). The resulting message violates section 3.6 of [MAIL] so the way it will be handled and displayed by an MUA is unpredictable - but in some cases they will display the newly added headers rather than those that are part of the originally signed message. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. It's also not specific to MUAs. Filtering agents can be similarly duped. They can, yes, though I'm not sure that's needed to explain why this may be a bad thing to allow. 1) Rejecting or treating as suspicious any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL], particularly those that are displayed to the end user (From, To, Cc, Subject). 2) Treating any message that has multiple copies of headers that are disallowed by section 3.6 of [MAIL] as not DKIM signed. These almost say the same thing to me. For example, treat as unsigned could be rolled into treat as suspicious. And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME. They're somewhat different. The first case involves recognizing that such messages are likely an attempt to be deceitful, and hence that the mail is unwanted. It's an approach that affects parts of the mail delivery system outside of DKIM, and will directly affect mail routing and delivery, and so can only be implemented by a broader system architect, not by a DKIM implementor. The second simply removes the DKIM-related benefit to this sort of attempt at deceit, removing the benefit of doing it. It doesn't make any broader judgement, and it can be handled entirely inside the DKIM verifier, without having any behavior change in the rest of the mail system, other than that implied by a lack of signature. And I'd prefer to show 3.6 as an example of a more general problem, in case later some vector is found using MIME. I'd prefer to stick to actual concerns, for now - stressing theoretical risks for which we have no idea how they could be implemented is a slippery slope. (I'm assuming that l= is going to be removed - if not, that would change things considerably as far as the likelihood of some sort of mime-related body change). If you concur, I'll take another run at it. Sure. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Monday, October 25, 2010 12:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues I'd strike during a replay attack because, as some have noted, the attack can be constructed deliberately on an original message. The real risk here is that someone can present a message as signed by someone trustworthy that has content different to that which was provided by the trusted signer. If the entity adding the additional content is the original signer, it may be a message composition bug, but it's not really any sort of attack on DKIM. Striking replay attack might make it less clear what the actual risk is, rather than more clear. (... can be abused, e.g. during a replay attack, by adding ... ?) Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target? It's also not specific to MUAs. Filtering agents can be similarly duped. They can, yes, though I'm not sure that's needed to explain why this may be a bad thing to allow. Focusing on the MUA case might inadvertently suggest to implementers of other components that this is not a concern for them. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Monday, October 25, 2010 12:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues I'd strike during a replay attack because, as some have noted, the attack can be constructed deliberately on an original message. The real risk here is that someone can present a message as signed by someone trustworthy that has content different to that which was provided by the trusted signer. If the entity adding the additional content is the original signer, it may be a message composition bug, but it's not really any sort of attack on DKIM. Striking replay attack might make it less clear what the actual risk is, rather than more clear. (... can be abused, e.g. during a replay attack, by adding ... ?) Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target? Not really, no. Signing the From: field means nothing other than that it is the same as when it was sent. I can sign mail with d=blighty.com and From: doola...@ebay.com without needing to play any games with multiple headers The only interesting attack in this entire situation is the ability to take a message signed by a high-reputation domain, so that it'll get delivered to the inbox, and to replace the Subject: (and possibly From:) with your own payload. It's also not specific to MUAs. Filtering agents can be similarly duped. They can, yes, though I'm not sure that's needed to explain why this may be a bad thing to allow. Focusing on the MUA case might inadvertently suggest to implementers of other components that this is not a concern for them. True. Though it really shouldn't be a significant concern for them, as filtering agents that are DKIM aware (should anyone create such a thing) and have a valid DKIM identity will likely use that in preference to, say, the From: field. And if the filtering agent is not DKIM aware, it's not an issue. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/25/10 2:12 PM, Steve Atkins wrote: On Oct 25, 2010, at 1:58 PM, Murray S. Kucherawy wrote: Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target? Not really, no. Signing the From: field means nothing other than that it is the same as when it was sent. I can sign mail with d=blighty.com and From: doola...@ebay.com without needing to play any games with multiple headers The only interesting attack in this entire situation is the ability to take a message signed by a high-reputation domain, so that it'll get delivered to the inbox, and to replace the Subject: (and possibly From:) with your own payload. Disagree. It could be signed by a large domain that is unlikely blocked, where the high value domain can then be spoofed because of a poorly defined DKIM verification process, regardless where the DKIM verification process happens to be located. It's also not specific to MUAs. Filtering agents can be similarly duped. They can, yes, though I'm not sure that's needed to explain why this may be a bad thing to allow. Focusing on the MUA case might inadvertently suggest to implementers of other components that this is not a concern for them. True. Though it really shouldn't be a significant concern for them, as filtering agents that are DKIM aware (should anyone create such a thing) and have a valid DKIM identity will likely use that in preference to, say, the From: field. And if the filtering agent is not DKIM aware, it's not an issue. DKIM verification is still DKIM verification regardless where this process is located. Stop hand waving. This process MUST be correctly defined to protect the consumers of these results. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/24/10 9:05 PM, Murray S. Kucherawy wrote: Here’s my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals. 8.14 Malformed Inputs The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: “Be conservative in what you do, be liberal in what you accept from others.” A number of popular email packages, including MTAs, MLMs, MUAs and so forth, thus forgive or ignore properties of messages that deviate from the standard format. A frequent example involves violations of Section 3.6 of [MAIL] which specifies minimum and maximum counts for particular header fields. Thus, a message with more than one From or Subject header field is not a legal email message, but most packages apply some trivial heuristic, e.g. use the first one and ignore the others, to interfere minimally with delivery of mail that might still be desirable to end users. This can expose those packages to subtle abuse vectors. For example, two different handlers of a message might identify the Subject field of a message by choosing the first one it finds. This would always produce the same result, regardless of whether the search is top-down or bottom-up, unless a message had more than one Subject field. Although [MAIL] specifically disallows this instance, it is tolerated by many mail handling agents, and so the possibility of confusion among implementations exists. This case becomes more interesting when one considers that a filtering agent might make a filtering decision based on one header field instance but a user agent might display the other. Knowing that this is the case, an attacker seeking to fool a user might exploit this to get past filters and render false data to a user. DKIM exacerbates this concern by assigning a signature to part or all of a message. It is possible that one could craft a message conforming to [MAIL], then affix a DKIM signature to it, and then add header fields atop the message that were not signed. Since many agents will overlook the fundamental invalidity of such a message, a DKIM verifier might produce a “valid signature” result while some other agent assumes an unsigned field is valid and applies it (e.g., renders it to a user) alongside some indication attesting to the message’s validity. This is especially concerning where one of the fields in question has to do with an identity, such as From or Sender. Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. Bad advice. There is no other email component that can be relied upon to restore flawed DKIM verification results, nor should DKIM relegate determination of DKIM result validity to subsequent consumers. This would be expecting all subsequent stages of email, represented by thousands of different applications, to repeat tests that now MUST be made to mitigate exploits. Without a MUST requirement in the verification process with respect to multiple From header fields, no DKIM results can be trusted for subsequent display or sorting processing. Nor should these processes be expected to conform with the DKIM bottom-up selection of headers that MUST be singular to be compliant with RFC5322. 2) Refuse outright to sign or verify any message that is not syntactically valid. Good advice. However, without a MUST normative language, DKIM results will be prone to attack. It is not reasonable to suggest consumers of DKIM results check something somewhere. This is NOT about enforcing compliance, this is about ensuring safe and actionable DKIM results. This can only be specified by the DKIM protocol. While lack of RFC5322 compliance might go unnoticed, a DKIM verifier MUST NEVER indicate a message with multiple From headers receive a PASS.Policy components could then indicate specific message handling. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). Incomplete advice. This only
Re: [ietf-dkim] Proposal for new text about multiple header issues
Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target? Not really, no. Signing the From: field means nothing other than that it is the same as when it was sent. I can sign mail with d=blighty.com and From: doola...@ebay.com without needing to play any games with multiple headers Let's say your message has two From lines, one from b...@blurfle.net, one from secur...@ebay.com, and you sign the first with d=blurfle.net. Perhaps blurfle.net even publishes discardable ADSP. My concern would be that filtering agents might notice the blurfle header and signature and deem it harmless, but an MUA would show the ebay header. In any event, I think it's reasonable to say that DKIM signers shouldn't sign a message with an extra From or Subject header, and verifiers shouldn't say the signature on such a message is good, even if it validates technically. I dug through my message archives last week, and I don't think I've ever seen a legit message with that flaw, so it's hard to think of a reason to cut such messages any slack. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 25, 2010, at 5:48 PM, John R. Levine wrote: Isn't the more interesting attack a signature from some throwaway domain that covered a matching From: but also contained a From: indicating some high-value phish target? Not really, no. Signing the From: field means nothing other than that it is the same as when it was sent. I can sign mail with d=blighty.com and From: doola...@ebay.com without needing to play any games with multiple headers Let's say your message has two From lines, one from b...@blurfle.net, one from secur...@ebay.com, and you sign the first with d=blurfle.net. Perhaps blurfle.net even publishes discardable ADSP. My concern would be that filtering agents might notice the blurfle header and signature and deem it harmless, If the filtering agent recognises blurfle.net then that would make blurfle.net someone trustworthy, and reduces to exactly the situation I was discussing 4 posts upstream. (The real risk here is that someone can present a message as signed by someone trustworthy...). If they've never seen blurfle.net before, then there's no reason to consider the signer trustworthy and your hypothetical filtering agent is broken. but an MUA would show the ebay header. In any event, I think it's reasonable to say that DKIM signers shouldn't sign a message with an extra From or Subject header, That doesn't really add much value, as you can always grab the signed message, add a header and resend it (unless you're also planning on mandating h=from:from:subject:subject). It's a perfectly reasonable policy for a DKIM signer to have, though. and verifiers shouldn't say the signature on such a message is good, even if it validates technically. Works for me, at least at the should-as-opposed-to-SHOULD level. I've said as much several times, and the only disagreements I've seen are people who are saying that that's not strict enough, and that DKIM verifiers also shouldn't verify a message that has, for example, bare linefeeds in it or a base 64 encoded section with an eighty character line in it. I dug through my message archives last week, and I don't think I've ever seen a legit message with that flaw, so it's hard to think of a reason to cut such messages any slack. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Proposal for new text about multiple header issues
Here's my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals. 8.14 Malformed Inputs The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. A number of popular email packages, including MTAs, MLMs, MUAs and so forth, thus forgive or ignore properties of messages that deviate from the standard format. A frequent example involves violations of Section 3.6 of [MAIL] which specifies minimum and maximum counts for particular header fields. Thus, a message with more than one From or Subject header field is not a legal email message, but most packages apply some trivial heuristic, e.g. use the first one and ignore the others, to interfere minimally with delivery of mail that might still be desirable to end users. This can expose those packages to subtle abuse vectors. For example, two different handlers of a message might identify the Subject field of a message by choosing the first one it finds. This would always produce the same result, regardless of whether the search is top-down or bottom-up, unless a message had more than one Subject field. Although [MAIL] specifically disallows this instance, it is tolerated by many mail handling agents, and so the possibility of confusion among implementations exists. This case becomes more interesting when one considers that a filtering agent might make a filtering decision based on one header field instance but a user agent might display the other. Knowing that this is the case, an attacker seeking to fool a user might exploit this to get past filters and render false data to a user. DKIM exacerbates this concern by assigning a signature to part or all of a message. It is possible that one could craft a message conforming to [MAIL], then affix a DKIM signature to it, and then add header fields atop the message that were not signed. Since many agents will overlook the fundamental invalidity of such a message, a DKIM verifier might produce a valid signature result while some other agent assumes an unsigned field is valid and applies it (e.g., renders it to a user) alongside some indication attesting to the message's validity. This is especially concerning where one of the fields in question has to do with an identity, such as From or Sender. Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. 2) Refuse outright to sign or verify any message that is not syntactically valid. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the h= portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
I mostly agree. (Wow!) 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. 2) Refuse outright to sign or verify any message that is not syntactically valid. Rather than be so absolutist, I'd say any message with syntax errors that are likely to cause MUAs or other applications to interpret it inconsistently. The thought is that two Subject lines is worth rejecting, an extra at sign in the Message-ID is not. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
-Original Message- From: John Levine [mailto:jo...@iecc.com] Sent: Sunday, October 24, 2010 9:25 PM To: ietf-dkim@mipassoc.org Cc: Murray S. Kucherawy Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues I mostly agree. (Wow!) Huzzah! 2) Refuse outright to sign or verify any message that is not syntactically valid. Rather than be so absolutist, I'd say any message with syntax errors that are likely to cause MUAs or other applications to interpret it inconsistently. The thought is that two Subject lines is worth rejecting, an extra at sign in the Message-ID is not. I'm fine with that if we think implementers will find it easier to construct a comprehensive likely list versus just enforcing the spec. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 9:05 PM, Murray S. Kucherawy wrote: Here’s my proposal for a section in Security Considerations to talk about the malformation issues that have been discussed on the list. This is an addition to -02 directly and does not continue from any of the other proposals. I like the sentiment, and the background up to here, but... Because of this, DKIM implementers are strongly advised to apply one or more of the following design decisions: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. 3) For any header field listed in Section 3.6 of [MAIL] as having an upper bound on the number of times it can appear, include the name of that field one extra time in the “h=” portion of the signature to prevent addition of fraudulent instances. Any attachment of such fields after signing would thus invalidate the signature (see Section 3.5 and 5.4 for further discussion). This works, and is definitely on the right track as it's looking at the specific problem rather than broad 5322 compliance, but feels like a hack workaround by the signer for a problem that's simpler for the receiver to deal with directly. It is something we can encourage that's strictly within the bounds of a DKIM spec, but that doesn't make it the ideal solution to the problem. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt to replay a DKIM signed message with different content. DKIM verifier implementors may consider messages that are malformed in this way as unsigned. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Sunday, October 24, 2010 9:56 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. You're not the outlier. I quite agree. [...] In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. What the text is trying to do is show the reader the caveats of the email world that exists today, not agreeing with or attempting to espouse that strategy. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On 10/24/2010 9:55 PM, Mark Delany wrote: Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. Jon Postel did not intend the interpretation that folks apply. As you note, carried to the current extreme, it produces silliness. His statement was meant to refer to the handling of protocol ambiguities. No matter how well a protocol is written, there are places that wind up being subject to slightly different interpretation. Especially during early stages of deployment, these ambiguities are discerned incrementally and often not resolved for quite awhile. In these circumstances, code that supports the differing interpretations is more robust. The situation with email comes from the rather different problem that complaints are from recipients and directed at their local operators, who have no control over the sources of the problems. So they hack their own code infinitely, to reduce local complaints. That produces the silly cruft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 9:55 PM, Mark Delany wrote: The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. A DKIM verifier generates a single bit, validly signed or not, and an identifier in the validly signed case. It doesn't pass mail along, well formed or not, nor does it control whether mail is passed on or not. All it can do is provide an identity for other pieces of the mail path to consider when making routing decisions. The only action a DKIM signer can take with regards to ill-formed email is to refuse to sign it. The only action a verifier can take with regards to ill-formed mail is to consider it unsigned, refusing to provide information to the rest of the mail delivery system. Given that, I don't think that either the DKIM signer or the DKIM verifier are the right place to take a stand against 5322 format violations. And that makes DKIM overall a poor place to do anything other than mention specific issues that directly affect the DKIM security model. Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Sunday, October 24, 2010 9:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Ah right. Need to be meticulous here. How about: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not. Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it. Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). The text is intended to be generic, referring to any entity that might consume a DKIM pass result. The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically. 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting. If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt to replay a DKIM signed message with different content. DKIM verifier implementors may consider messages that are malformed in this way as unsigned. Maybe that can be some example-type text tacked on to the second bullet point? ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Proposal for new text about multiple header issues
On Oct 24, 2010, at 10:15 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Steve Atkins Sent: Sunday, October 24, 2010 9:54 PM To: IETF DKIM WG Subject: Re: [ietf-dkim] Proposal for new text about multiple header issues 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, consider as valid only those fields and the body portion that was covered by the signature. Note that this is not to say unsigned content is not valid, but merely that the signature is making no statement about it. There are a couple of issues with this. First, it implies that if a DKIM signature does cover a header, then that DKIM signature is saying that that header is valid, which isn't the case in general. Ah right. Need to be meticulous here. How about: 1) During the handling of a message in conjunction with a DKIM result that indicates a valid signature, observe the distinction between those parts of the header and body that were covered by the signature and those that were not. Note that this is not to say unsigned content is not valid, but merely that the signature makes no statement about it. That still expands the API from the DKIM verifier quite a lot - it requires the verifier to explicitly list which headers are signed, and which aren't (that the h= field doesn't do that is what we're having problems with). It would also require that to be pushed all the way downstream to other pieces of software, perhaps via something similar to an extended Authentication-Results type of header. That's not impossible, but seems very complex for the specific problem we're considering - we just need to communicate This message violated 5322, specifically in a way that makes us think the sender is trying to game DKIM (either by flagging the mail as syntactically invalid and suspicious at some point in the mail stream, or invalidating the DKIM signature). Second, this is nearly meaningless operationally. for the sort of attack that's been envisioned (showing different author or subject in an apparently signed message), as there's no real way to consider any particular field as valid or invalid (unless you're communicating the information all the way to the MUAs display code, or you're deleting headers in transit - which are both possibilities, but ones that would need to be called out explicitly). The text is intended to be generic, referring to any entity that might consume a DKIM pass result. The particularly interesting ones are of course the MUAs and anything that does authentication of a service (e.g., an MLM) based on a signed field, but I was trying to avoid talking about them specifically. If we need to communicate a list of valid headers to downstream consumers of a DKIM pass result it's a lot more complex than a simple pass/fail and we'd need to consider what that API might be (partly so we're clear on what data in addition to a DKIM pass, here's your d= we're communicating). 2) Refuse outright to sign or verify any message that is not syntactically valid. This is overly strong, as a lot of messages that are not 5322 valid are wanted (bare linefeeds, amongst other issues). Encouraging signers or verifiers to deny the existence of a DKIM identity in those cases just makes it harder to distinguish between wanted invalid mail and unwanted invalid mail. This is the informative equivalent of the normative SHOULD/MUST upon which people were insisting. Yup. It's a backdoor SHOULD, and I don't like it for the same reason :). If you think it would help, we could call out specifically 3.6 of 5322, but the risk there is that people will harden against that vector only to have something else come up later that we didn't call out specifically. I'm more concerned with the suggestion that *any* violation of 5322 (or 2045 and friends - it's all syntax) is grounds for refusing to validate a message. I think that DKIM verifiers refusing to pass on a d= identifier due to trivial format violations is likely to reduce the quality of the mailstream rather than increase it. (Those violations may well be grounds for another part of the mail handler to reject the mail altogether, but that's outside DKIMs main job of providing an identifier to help the downstream mail handlers make informed decisions.) Focussing on just those issues that may affect the DKIM security model (which, if we kill off l=, is likely to just be adding unsigned headers) seems like it'd push implementors in a more useful direction. Something that's more to the point we're concerned about might be more like A mail system that considers DKIM signatures during mail delivery should treat with suspicion any email that has multiple copies of any header where RFC 5322 requires they have no more than one, as it may be an attempt
Re: [ietf-dkim] Proposal for new text about multiple header issues
Mark Delany wrote: The universe of email is replete with software that forgives messages which do not conform strictly to the grammar that defines what valid email looks like. This is a long-standing practice known informally as the robustness principle, originally coined by Jon Postel: Be conservative in what you do, be liberal in what you accept from others. Well, I'm clearly the outlier here, but I think be liberal is protocol nonsense that has been accepted as conventional wisdom for far too long now. Put another way, Accept crud and pass it on constitutes good protocol design? Gimme a break. More particularly, DKIM is a security protocol which means that being liberal is entirely antithetical and highly risky to boot. In short, I don't think any part of DKIM should be based on be liberal because it always trades off security. Really, its an inappropriate attempt in a history lesson and it actually doesn't apply here. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
