Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Monday, October 04, 2010 5:49 PM To: jdfalk-li...@cybernothing.org Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report We are not holding up the dkim spec, we are wanting a datapoint to be kept in the draft-ietf-dkim-implementation-report But: a) It's technically out of scope, i.e. it's not a data point relevant to DKIM itself since RFC4871 doesn't say anything at all about a binding between d= and anything else in the message, so its removal would actually be justified; however b) It was not actually removed from the draft, it was simply reworded to be more precise as suggested by one of the other participants[1]. It's right there on page 10, at least on the version I'm looking at on the IETF web site. So are you saying you want the old wording back for some reason? If not, I don't see what the complaint is. It looks like I dropped the AOL version of the same statistic by mistake. I'll add it back in after last call completes. Gmail did not provide me with their version of that statistic. Since it's of such interest, I'll ask for it, but I may not get it. -MSK [1] http://mipassoc.org/pipermail/ietf-dkim/2010q4/014572.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
--On 4 October 2010 18:24:11 -0400 Hector Santos hsan...@isdg.net wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers *and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. For example: From: phis...@badguy.com-- injected, replayed, shown by MUA DKIM-Signature: d=signer.com ...; From: sig...@address.com-- hash bound to signature The MUA will display the injected 5322.From header and the signature is still valid because it only signed the bottom one and verifiers also use this header to validate the signature. A review of the the 4871 specification shows this statement in section 5.4 which can explains how this is possible: 5.4. Determine the Header Fields to Sign ... Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. There needs to be a special consideration where: 1) Verifiers and MDAs consider checking for violating RFC5322 messages with multiple 5322.From headers and rejected it, or 1) hash verification should be done for all 5322.From fields and not just the last one as the above paragraph implies. 2) signing should be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have should to display only the first 5322.From header found. -- 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] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
--On 4 October 2010 23:15:05 -0400 Hector Santos hsan...@isdg.net wrote: Murray S. Kucherawy wrote: The term third-party was removed because DKIM itself doesn't say anything about a binding between d= and anything else in the message. That concept is first presented in ADSP. Since the implementation report is only about DKIM itself, not ADSP, discussing author vs. third party is actually irrelevant. -1 It is extremely relevant. The data is there. The numbers can be calculated from the sample size (~500k) and the proportions. They're nowhere near the numbers (Originator signatures: 1.2 billion Third-party signatures: 184 million) that you quoted in another email, which also don't match the proportions that you quoted. Where did 1.2 billion come from? Third party is somewhat of a leap from the domains don't match. For example, if the from header is in the domain example.com and we see d=foo.example.com, is that really a third party signature? Perhaps some clarity of whether subdomains were permitted to match would be useful.* Oh, and are you thinking this is about implementation of ADSP? I think it's supposed to be about implementation of DKIM, so that DKIM can be progressed. Please don't let a misunderstanding hold that process up. Its an implementation data report about observed operations and consistent per chapter itemized goals: 2. Collect data on the deployment, interoperability, and effectiveness of the base DKIM protocol, with consideration toward updating the working group's informational documents. 3. Collect data on the deployment, interoperability, and effectiveness of the Author Domain Signing Practices protocol (RFC 5617), and determine if/when it's ready to advance on the standards track. Update it at Proposed Standard, advance it to Draft Standard, deprecate it, or determine another disposition, as appropriate. 4. Taking into account the data collected in (2) and (3), update the overview and deployment/operations documents. These are considered living documents, and should be updated periodically, as we have more real-world experience. The empirical data is on par with #2, #3 and thus #4. It provides the field testing and engineering insights and information people need to progress with DKIM in a better way without blinders. I don't get you guys, doing this to push a standard. If you think this is kolsher - its not. * It would be interesting to know what proportions of author addresses were subdomains of the d= value, and vice-versa. Even to know if the domains share common whois registrations (like foo.example.com and bar.example.com) would be nice, though harder to do. Having said all that, I have my own log files that I could analyze, so I'll shut up. -- 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] New Version Notification for draft-ietf-dkim-mailinglists-03
--On 4 October 2010 14:16:48 -0700 Murray S. Kucherawy m...@cloudmark.com wrote: However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. Good plan. That would be rather pointless. -- 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] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
On 10/5/2010 8:15 AM, Ian Eiloart wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers*and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Your comments underscore the importance of being careful about what we expect from DKIM. As you note, if software is DKIM-aware, it also needs to be DKIM-intelligent. At a deeper level, there is a continuing problem with casting DKIM as a mechanism to protect a message. That's something that OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely tries to do enough to ensure that the d= is valid, to provide a basis for reputation assessment. Hence, I recommend that this ISSUE be declined and closed. 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] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
sorry, jumped a passing bandwagon, good to go then On Oct 4, 2010, at 10:36 PM, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of bill.ox...@cox.com Sent: Monday, October 04, 2010 3:11 PM To: hsan...@isdg.net Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics I would be curious also but would be happy with a 73% of the signatures were author signatures meaning the d= value in the signature matched the domain found in the From:header field and let the reader draw their own conclusions And that's what's still there. First half of page 10. The term third-party was removed because DKIM itself doesn't say anything about a binding between d= and anything else in the message. That concept is first presented in ADSP. Since the implementation report is only about DKIM itself, not ADSP, discussing author vs. third party is actually irrelevant. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
Ian Eiloart wrote: -1 It is extremely relevant. The data is there. The numbers can be calculated from the sample size (~500k) and the proportions. They're nowhere near the numbers (Originator signatures: 1.2 billion Third-party signatures: 184 million) that you quoted in another email, which also don't match the proportions that you quoted. Where did 1.2 billion come from? Sounds like revision v02 is already having its intended effect. Ian, see the previous revision v01 section 4.2 http://tools.ietf.org/html/draft-ietf-dkim-implementation-report-01#section-4.2 In fact, what was left in rev 02 was Murry's 78.9% for the OpenDKIM observation of 1st vs 3rd. What was removed was the AOL data point. I stated it as 86% here: http://mipassoc.org/pipermail/ietf-dkim/2010q3/014556.html Third party is somewhat of a leap from the domains don't match. Third party per RFC 5016 is well defined. For example, if the from header is in the domain example.com and we see d=foo.example.com, is that really a third party signature? Perhaps some clarity of whether subdomains were permitted to match would be useful.* It doesn't matter. The Observed data is what counts. Per RFC 5016 definitions, this is what we got X for that, Y for this. Oh, and are you thinking this is about implementation of ADSP? As an engineer I look at data, look for patterns, see how they correlate to logical protocols and even justify experiments and problem solving. To me, the data points show there is a strong 1st party stream of mail. POLICY would be important here. But that is not what the report is about. For example, if the report showed the opposite, over 70% of the mail stream was 3rd party (5322.From != DKIM.d per RFC 5016), rest assured, we would be hearing how much POLICY or ADSP is insignificant and should be deprecated - and I would AGREE. The reality is the overwhelming 1st party mail continues to justify a need for policy. But that is my interpretation, not what the report is about. I think it's supposed to be about implementation of DKIM, so that DKIM can be progressed. Please don't let a misunderstanding hold that process up. Its not an mis-understanding. There is nothing holding back DKIM but this constant interference with the reality. Embrace and see how things change. What the factoid removal does is goes against chartered itemize goals of #2, #3 and #4. * It would be interesting to know what proportions of author addresses were subdomains of the d= value, and vice-versa. Even to know if the domains share common whois registrations (like foo.example.com and bar.example.com) would be nice, though harder to do. Having said all that, I have my own log files that I could analyze, so I'll shut up. Your, all data would be welcomed too. Soon I will have accumulated data as well. Currently working out how to present them in our web-view of the statistics. IOW, adding DKIM/POLICY related columns to these statistics: http://www.winserver.com/public/spamstats.wct -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On 10/04/2010 10:41 PM, Barry Leiba wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I've reviewed it and came across the following: Chapter 2: as for DKIM specific definitions used in this document, they cannot be found in [EMAIL-ARCH]. Please add [DKIM] here as source of definitions. Par. 3.2 - 3.4: these paragraphs are a bit 'vague', due to terms like 'Some implementations [...]', 'Some test cases [...]', 'at least two implementations...'. Presumably this has to do with the fact that the interoperability event took place long time ago? If so, I'd suggest to include a sentence to describe the difficulty to gather all relevant information, three years after the event took place. To make these paragraphs a bit less 'vague' I would like to suggest to include the original set(s) of test messages and the original interoperability test plan(s), if still around somewhere. Par. 4.1.2: [...] Where list mail is defined as [...] Should this not be: [...] Where Non-List Mail is defined as [...]? Murray, thanks for the work! /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
I've removed Tim Polk from the Cc: list because he is not our sponsoring AD. Our sponsoring AD is already on this list. -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Tuesday, October 05, 2010 5:15 AM To: Hector Santos; ietf-dkim@mipassoc.org Cc: Tim Polk Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers *and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. This is a non-issue for DKIM anyway. All of this work is predicated on an email that's properly formatted, and RFC5322 says a message with multiple From: headers is malformed. So this is not specifically an attack on DKIM. I don't think it's practical in DKIM to enumerate all the ways various malformations can cause misleading displays in an MUA. The MLM draft work included some chatter about some advice for MUA implementers. If and when that work is consolidated into a new document of some kind, this issue would be a good one to put there. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Tuesday, October 05, 2010 4:56 AM To: Hector Santos; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Issue: implementation Report v02 - Removal of 1st vs 3rd party statistics Oh, and are you thinking this is about implementation of ADSP? I think it's supposed to be about implementation of DKIM, so that DKIM can be progressed. Please don't let a misunderstanding hold that process up. Yes, that's precisely right. The purpose of the implementation report is to discuss DKIM's interoperability only, to satisfy certain IESG requirements. Nothing more. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On 10/05/2010 04:07 PM, Murray S. Kucherawy wrote: Hi Rolf, -Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Tuesday, October 05, 2010 6:27 AM To: Barry Leiba Cc: DKIM Mailing List; Murray S. Kucherawy Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report Chapter 2: as for DKIM specific definitions used in this document, they cannot be found in [EMAIL-ARCH]. Please add [DKIM] here as source of definitions. The top of chapter 2 contains [DKIM] which is the formal reference to that specification. Are we looking at the same report? I used http://tools.ietf.org/html/draft-ietf-dkim-implementation-report which brings me to version 02 of the document. I see [DKIM] mentioned here and there, throughout the document, but not in chapter 2? Or do you mean the page header, which mentions RFC4871 and of course presents the same referral as [DKIM] gives? [EMAIL-ARCH] is a general tutorial/overview about email architecture, included to help any newcomers to understand the context of the whole work. I know [EMAIL-ARCH], it's definitely a good choice to refer in your document to this architecture RFC. Par. 3.2 - 3.4: these paragraphs are a bit 'vague', due to terms like 'Some implementations [...]', 'Some test cases [...]', 'at least two implementations...'. Presumably this has to do with the fact that the interoperability event took place long time ago? The language of that section is just a general description of the participants (the software, specifically) in the interop event and what they brought to the party. The thrust is actually to show that they were all diverse, i.e. that a number of different parties wrote code per the RFC and then tried to send mail to each other to see what happens. It would be uninteresting to have 20 parties come together all running different installations of the same package. Showing diversity in an interoperability report is quite important. Changing Some test cases to Test cases seems fine to me. At least two implementations is a specific IETF requirement for an interop report. I actually am pretty sure all implementations there implemented even all of the optional stuff, except z=, but I don't have any specific record saying that so I'm making only the weaker of the two statements. OK. If so, I'd suggest to include a sentence to describe the difficulty to gather all relevant information, three years after the event took place. To make these paragraphs a bit less 'vague' I would like to suggest to include the original set(s) of test messages and the original interoperability test plan(s), if still around somewhere. There wasn't a formal plan. It was basically send all your tests at all the participants, then work with each of them to figure out what failed and why. Each participant brought its own corpus of test messages. Unfortunately very little of the actual test data and results documentation still exist, mainly because of a promise among the participants to keep the results about specific implementations private. OK, then maybe that's something that needs to be mentioned, to explain why that part of the report is less exact than for example the data points about OpenDKIM and AOL. The public result, appropriately, was the group's evaluation of the quality of the RFC and the published list of errata. Apart from these minor remarks, in my view, it's ready to go. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
-Original Message- From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] Sent: Tuesday, October 05, 2010 7:36 AM To: Murray S. Kucherawy Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Working group last call on draft-ietf-dkim- implementation-report Are we looking at the same report? I used http://tools.ietf.org/html/draft-ietf-dkim-implementation-report which brings me to version 02 of the document. I see [DKIM] mentioned here and there, throughout the document, but not in chapter 2? Or do you mean the page header, which mentions RFC4871 and of course presents the same referral as [DKIM] gives? Sorry, you're right; the first [DKIM] reference is in Section 1. For completeness, I'll add it to Section 2 as well. OK, then maybe that's something that needs to be mentioned, to explain why that part of the report is less exact than for example the data points about OpenDKIM and AOL. Yep, that seems reasonable. I'll do that as well. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Hector Santos wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. For example: From: phis...@badguy.com-- injected, replayed, shown by MUA DKIM-Signature: d=signer.com ...; From: sig...@address.com-- hash bound to signature The MUA will display the injected 5322.From header and the signature is still valid because it only signed the bottom one and verifiers also use this header to validate the signature. A review of the the 4871 specification shows this statement in section 5.4 which can explains how this is possible: 5.4. Determine the Header Fields to Sign ... Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. There needs to be a special consideration where: 1) Verifiers and MDAs consider checking for violating RFC5322 messages with multiple 5322.From headers and rejected it, or 1) hash verification should be done for all 5322.From fields and not just the last one as the above paragraph implies. 2) signing should be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. I propose the following addition text by adding to 48721bis to address this serious issue; No. The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Perhaps this could be mentioned in the spec with a specific reference to the From header, but in general terms the spec is pretty clear about how to prevent the addition of a header field. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Julian Mehnle wrote: Hector Santos wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. No. The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. Perhaps this could be mentioned in the spec with a specific reference to the From header, but in general terms the spec is pretty clear about how to prevent the addition of a header field. If you referring having duplicate from: in h= mitigate this issue, see above. As I proposed, the semantics must include an exception clause for the Verifier and Signer signing 5322.From binding logic as described in section 5.4 to address this. It also needs to recommend that MTAs do RFC5322 validating as well - but you are not going to find this in the wild unless the MTA is DKIM compliant and is aware of this situation. It has to be documented in 4871bis for DKIM standardization to make implementations now and the future aware of it and deal with it. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
On 10/5/10 8:45 AM, Dave CROCKER wrote: At a deeper level, there is a continuing problem with casting DKIM as a mechanism to protect a message. That's something that OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely tries to do enough to ensure that the d= is valid, to provide a basis for reputation assessment. Deeper still, DKIM prevents false positive phishing detection. But since a bad actor can poison reputation whenever verification of a DKIM domain is associated with undesired delivery, such use suggests DKIM as a basis for reputation will not work. It would be accurate to say DKIM provides a basis for white-listing based upon information derived by other means, and offers a strong basis to apply acceptance policy based upon associations with the From header field. However, this policy also needs to consider legitimate third-party services to discourage the bad practice of using sub or cousin domains with MX records or MTAs lacking restrictive authentication policies, since this would make the phishing problem even more intractable. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Julian Mehnle Sent: Tuesday, October 05, 2010 7:27 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From No. The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. But the attacker in this scenario is already the signer (or has compromised the signer), so he/she will just sign the single From:. Perhaps this could be mentioned in the spec with a specific reference to the From header, but in general terms the spec is pretty clear about how to prevent the addition of a header field. From: is already there. The RFC explains how to prevent addition of a field that wasn't there to begin with, not to prevent addition of new ones. Enumerating MUA issues, though, is a bottomless pit and not really within our scope to do. We should avoid it. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Ian Eiloart wrote: --On 4 October 2010 18:24:11 -0400 Hector Santos hsan...@isdg.net wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers *and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Ian, it would be not practical to expect MUAs to address this. But sure a recommendation for MTAs and MUA to validate RFC522 specifically in regards to 5322.From would suffice. As Keith Moore recently stated in IETF-822: Okay, I'll state it with more precision: The checking of headers should only occur when such a feature is actually being used: e.g. when the message is actually being submitted, being filtered for spam specifically on behalf of a sender or recipient, or being gatewayed into (or out of) a foreign (non-Internet) mail system. His point, in IMV, is that you are not going to find many MTA doing RFC 822/2822/5322 checking unless it has a specific purpose. A DKIM ready ADMD or MTA receiver might be able to reject/drop invalid mail with multiple 5322.From lines. We added a script for this ourselves. But to cover all loopholes the DKIM-verifier MUST have an additional requirement to fault a message with 2 or more 5322.From lines. That is exactly what the ALT-N open source DKIM/ADSP API did - added an additional requirement for DKIM verification that is above and beyond what the current specs says and currently allows. The whole point of a BIS is to help codify the implementation field testing and experiences which alter or fine tunes the proposed draft protocol. This one chalks up as on par with what we are seeking. -- 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] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Murray S. Kucherawy wrote: But the attacker in this scenario is already the signer (or has compromised the signer), so he/she will just sign the single From:. If the attacker is the signer, they can just as well resign many times. I don't think that's the scenario that Hector meant, though. Perhaps this could be mentioned in the spec with a specific reference to the From header, but in general terms the spec is pretty clear about how to prevent the addition of a header field. From: is already there. The RFC explains how to prevent addition of a field that wasn't there to begin with, not to prevent addition of new ones. No, read section 5.4 again. Hector even quoted the relevant parts in his thread opening message. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Julian Mehnle Sent: Tuesday, October 05, 2010 9:28 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From From: is already there. The RFC explains how to prevent addition of a field that wasn't there to begin with, not to prevent addition of new ones. No, read section 5.4 again. Hector even quoted the relevant parts in his thread opening message. Ah, I see now. I understand 5.4, but I've only ever applied it to preventing addition of a header field that wasn't there in the first place, not to prevent addition of a second one. That's a pretty clever solution. Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Please don't CC me. I'm subscribed to the list. Hector Santos wrote: Julian Mehnle wrote: The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. I don't get what you're saying. I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted originally), such that signing a message that has a dingle From field with h=From:From ensures that adding another From field will break the signature. If you're saying there is a way to add a second From field a message thusly signed without breaking the signature, could you please explain to me how? -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Comments inline -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim- boun...@mipassoc.org] On Behalf Of Dave CROCKER Sent: Tuesday, October 05, 2010 8:45 AM To: Ian Eiloart Cc: Tim Polk; ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From On 10/5/2010 8:15 AM, Ian Eiloart wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers*and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Your comments underscore the importance of being careful about what we expect from DKIM. As you note, if software is DKIM-aware, it also needs to be DKIM-intelligent. Agreed. At a deeper level, there is a continuing problem with casting DKIM as a mechanism to protect a message. That's something that OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely tries to do enough to ensure that the d= is valid, to provide a basis for reputation assessment. As long as DKIM signs the body and fails to validate on a signed but modified body then there has to be some presumption that DKIM is a mechanism (of some sort) that protects the message (to some extent). Hence, I recommend that this ISSUE be declined and closed. I'm still cogitating on the appropriate response to this ISSUE. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
On Mon, Oct 4, 2010 at 4:41 PM, Barry Leiba barryle...@computer.org wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: http://tools.ietf.org/html/draft-ietf-dkim-implementation-report The working group last call will run through Friday, 22 October, 2010. This implementation report will be used to advance the DKIM base spec to Draft Standard. Everyone please review it, and post comments/issues. Please also post here if you've reviewed it and think it's ready to go. I find sections 4.2 and 4.3 hard to compare. It could be just me. That is just my quick observation. -- Jeff Macdonald Ayer, MA ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Dave CROCKER d...@dcrocker.net wrote: On 10/5/2010 8:15 AM, Ian Eiloart wrote: It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. Ouch. That's nasty. But wouldn't it be better to advise MUA vendors to display the signed header? Are there really MUA's that will display the unsigned headers*and* assert that it was validated? If so, that's surely a bug in the implementation of the MUA. Your comments underscore the importance of being careful about what we expect from DKIM. As you note, if software is DKIM-aware, it also needs to be DKIM-intelligent. At a deeper level, there is a continuing problem with casting DKIM as a mechanism to protect a message. That's something that OpenPGP and S/Mime do; it's not something DKIM does. DKIM merely tries to do enough to ensure that the d= is valid, to provide a basis for reputation assessment. Hence, I recommend that this ISSUE be declined and closed. Nack. DKIM also purports to provide assurance that the signed content of the message is unmodified. I think mentioning that all instances of a header that is signed should be used for signing and verification is a useful data point for implementors. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Tuesday, October 05, 2010 12:24 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From Nack. DKIM also purports to provide assurance that the signed content of the message is unmodified. I think mentioning that all instances of a header that is signed should be used for signing and verification is a useful data point for implementors. I'm having trouble parsing that. Aren't all instances of a signed field used for verifying already? Or are you proposing an If you sign one, you have to sign them all sort of approach? That will wreak havoc with Received:, if so. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New Version Notification for draft-ietf-dkim-mailinglists-03
My perception of the rough consensus is that we do want to make some statements about the issues discussed in the draft. However, the only truly normative thing upon which we appear to agree is that MLMs should sign their mail. I would rather we produce this more complete document at a lower status than a one-paragraph BCP saying only that. If we do that, I think that in fairness to people reading it, we should say explicitly which recommendations are based on practice, and which are paper designs a/k/a wild guesses. Unless I've missed some implementations, we have considerable experience with lists signing, and some anedotal experience with damage from ADSP, but everything else falls into the latter category. I'm also scratching my head about the bits that are intended to help people work around faulty DKIM implementations. Are there other IETF documents that do that? R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top ... A thing with two From: headers isn't a valid RFC 5322 message. You may recall a lengthy argument about what to do with messages with bare carriage returns, with the final conclusion being don't do that. DKIM is only defined to sign valid messages. If a MUA does something undesirable with invalid messages, I'd encourage people to improve their MUAs. I expect that an MUA that does something wacky with extra From: lines also does something wacky with extra Subject: or other extra lines. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Julian Mehnle wrote: Hector Santos wrote: Julian Mehnle wrote: The trick is to list From twice in h=. This ensures more From headers cannot be added without breaking the signature. Julian, this was explored and it does not matter. You can add N number of h=from: and N+1 is all that is needed in the security hole. I don't get what you're saying. I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted originally), such that signing a message that has a dingle From field with h=From:From ensures that adding another From field will break the signature. If you're saying there is a way to add a second From field a message thusly signed without breaking the signature, could you please explain to me how? You are correct. Adding a second from: to the h= tag: h=from:from:.. can address this. But no implementation does that. Instead the ALT-N open source code library counts the 2nd in the verification process and invalidates the signature. My earlier response to you got mixed up with SIGNING test cases where there was multiple 5322.From and multiple from: adding to the h=. Example: From: --- Injected, Replayed and MUA Display From: --- satisfy 2rd hash binding DKIM-Signature: h=from:from: From: --- satisfy 1rd hash binding and EXPECTED MUA Display So you have N number of h=from SIGNER binding, and you need N+1 to exploit it in the VERIFICATION. Of course, you would have violate 5322 in the first place to have a 2nd bound 5322.From. So no good guy will do this. But bad guys will see your typical single 5322.From and one from: in the h= tag. Either way, there is a security issue and a new requirement to secure it either with your suggestion or changes to the guidelines to check for this exception. Obviously, the ease of this exploit is a concern. Any high value domain mail can now be found and replayed with a phished or spooked 2nd or more 5322.From: -- 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] signing and verifying invalid messages
Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Hector Santos wrote: Julian Mehnle wrote: I interpret RFC 4871, section 5.4 (actually, exactly the part you quoted originally), such that signing a message that has a dingle From field with h=From:From ensures that adding another From field will break the signature. If you're saying there is a way to add a second From field a message thusly signed without breaking the signature, could you please explain to me how? You are correct. Adding a second from: to the h= tag: h=from:from:.. can address this. But no implementation does that. I don't think this is a matter of implementation, but one of *configura- tion*. Are there any DKIM implementations that *hard-code* the value of h=? In any case I think all that's warranted is adding an explicit note that From should be included in h= twice, be it in a hard-coded (default) value or in user-made configuration. [...] Obviously, the ease of this exploit is a concern. Any high value domain mail can now be found and replayed with a phished or spooked 2nd or more 5322.From: Agreed. Assuming you're right and single-From h='s are indeed a frequent configuration, then apparently the significance of this was underestimated. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] signing and verifying invalid messages
Michael Thomas wrote: On 10/05/2010 01:36 PM, John Levine wrote: Still, though, it's a solution to deal with malformations to which MUAs are susceptible, and not strictly a DKIM problem. Would it be a good idea to recommend in 4871bis that DKIM implementations should not sign or verify invalid messages? I cheerfully admit that I haven't thought out all the implications thereof. I'd suggest that it would be better to take that up with rfc5822-bis since this is hardly a dkim-specific problem. In my engineering opinion, it was a security hole that fell through the cracks during the development of the RFC 4886 Threat Analysis. If it was presented back then, we would be dealing with the semantics as I propose to deal with it simply because we can't ignore it or blame RFC 822/2822/5322 implementation or MUAs. This is a DKIM issue and it needs to get addressed. Any system today that displays: signed by: but displays a spoofed 2nd From can produce a major confidence problem for DKIM. I have a problem understanding the blow back to the security issue. 4871bis is active. Something needs to be added to 4871bist so that implementations and operators are made aware of it, now and into the future. I highly recommend that the key editors embrace this and deal with it or risk negative DKIM public relations if this gets into the media or into the mind set of any hackers and potential DKIM exploiters. You need to deal with it. Not ignore it or pass the buck to other layers of email. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com [1] http://tools.ietf.org/html/rfc4686 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From
Murray S. Kucherawy m...@cloudmark.com wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Scott Kitterman Sent: Tuesday, October 05, 2010 12:24 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] ISSUE: 4871bis - Security Loop hole with Multiple 5322.From Nack. DKIM also purports to provide assurance that the signed content of the message is unmodified. I think mentioning that all instances of a header that is signed should be used for signing and verification is a useful data point for implementors. I'm having trouble parsing that. Aren't all instances of a signed field used for verifying already? Or are you proposing an If you sign one, you have to sign them all sort of approach? That will wreak havoc with Received:, if so. I'm suggesting making it clear that if one signs a type of field they should sign all of them. I'm not suggesting adding any requirements that additional types of fields be signed. Scott K P.S. I'm not sure I parsed your question correctly. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Working group last call on draft-ietf-dkim-implementation-report
At 13:41 04-10-10, Barry Leiba wrote: Thus begins working group last call on the DKIM implementation and interoperability report, draft-ietf-dkim-implementation-report-02: I read the implementation report for RFC 4871 (draft-ietf-dkim-implementation-report-02). It addresses the comments I raised previously. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
THIS IS A MULTIPLE 5322.FROM SPOOFED MESSAGE It has been observed by implementations that is it possible to replay a message with a 2nd 5322.From header at the top which wouldn't break the DKIM signature validity, but would often be displayed by MUAs to display the new 5322.From display rather than the signature bound 5322.From header. For example: From: phis...@badguy.com-- injected, replayed, shown by MUA DKIM-Signature: d=signer.com ...; From: sig...@address.com-- hash bound to signature The MUA will display the injected 5322.From header and the signature is still valid because it only signed the bottom one and verifiers also use this header to validate the signature. A review of the the 4871 specification shows this statement in section 5.4 which can explains how this is possible: 5.4. Determine the Header Fields to Sign ... Signers choosing to sign an existing header field that occurs more than once in the message (such as Received) MUST sign the physically last instance of that header field in the header block. Signers wishing to sign multiple instances of such a header field MUST include the header field name multiple times in the h= tag of the DKIM-Signature header field, and MUST sign such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name in h= than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added. There needs to be a special consideration where: 1) Verifiers and MDAs consider checking for violating RFC5322 messages with multiple 5322.From headers and rejected it, or 1) hash verification should be done for all 5322.From fields and not just the last one as the above paragraph implies. 2) signing should be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
President Obama wrote: [...] Funny, but this shows nothing because mipassoc.org resigns messages (d=mipassoc.org). (Oh, and it even included *two* Froms in h= on your message.) I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -1. Why do you insist on changing the hashing semantics to special-case From? Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: President Obama wrote: [...] Funny, but this shows nothing because mipassoc.org resigns messages (d=mipassoc.org). (Oh, and it even included *two* Froms in h= on your message.) Right. Does this add signer reputation weight for the injected 5322.From? Not good. If mipassoc.org is being vouched by some 3rd party reputation service. The user sees a signed valid message possibly vouched by trusted service with a signature hash bound spoofed 5322.From. I propose the following addition text by adding to 48721bis to address this serious issue; Special Consideration for Verifying and Signing From: Header As an exception, header hash verification MUST be done for all 5322.From fields and not just the last one. Signing MUST be done for all 5322.From fields found, even though RFC5322 recommends only one 5322.From should be used. This will mitigate any replay that prepends a new 5322.From header to a DKIM signature valid message. Some MUAs have shown to display only the first 5322.From header found. -1. Why do you insist on changing the hashing semantics to special-case From? Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Not proposing a to change the semantics. But rather to add insight about the issue so that implementators can deal with it. For example, when I received the echo back from the list, my MTA rejected it. 18:46:07 C: MAIL From:ietf-dkim-boun...@mipassoc.org SIZE=5329 18:46:07 S: 250 ietf-dkim-boun...@mipassoc.org 18:46:07 C: RCPT To:hsan...@isdg.net 18:46:08 S: 250 hsan...@isdg.net... Recipient ok 18:46:08 C: DATA 18:46:08 S: 354 Start mail input; end with CRLF.CRLF 18:46:08 ** end of data received. (bytes: 5738) 18:46:08 ** WCX Process: SmtpFilterHookLoader ret: 0 18:46:08 ** Invalid 5322 Message - multiple From: headers not allowed 18:46:08 S: 551 Message Not Accepted by filter. 18:46:10 C: QUIT 18:46:10 S: 221 closing connection Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. However, if you are suggesting that it needs to be explicitly defined to mitigate this problem, then the specs needs to be updated to address the security issues. The fact, Mipassoc.org, stripped my original header and signed with the double from: lines, one real, one an injected spoofed, proves exactly what the problem here is. I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hector Santos wrote: Right. Does this add signer reputation weight for the injected 5322.From? Probably not. AFAICT mipassoc.org doesn't verify DKIM sigs on list messages, and even if it did, a verified DKIM sig (such as one created by the original author of the message) doesn't tell anything about the legitimacy of the use of the From identity. Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. No. h= must not be empty. The spec explicitly forbids this. Cf. http://tools.ietf.org/html/rfc4871#page-20 h= [...] This list MUST NOT be empty. [...] As for a possible change in RFC 4871bis, if you look at page 41 of 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: | INFORMATIVE NOTE: A header field name need only be listed once | more than the actual number of that header field in a message at | the time of signing in order to prevent any further additions. | For example, if there is a single Comments header field at the | time of signing, listing Comments twice in the h= tag is | sufficient to prevent any number of Comments header fields from | being appended; it is not necessary (but is legal) to list | Comments three or more times in the h= tag. I suggest replacing Comments with From. That should solve the problem. -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Again, please don't CC me. I'm subscribed to the list. Stephen Farrell wrote: On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. Yeah, possibly. I wasn't even thinking of using RFC 2119 verbiage. As I've written in my previous mail I think there's a better way to solve this (non-)issue. Just s/Comments/From/ in that INFORMATIVE NOTE on page 41 of 4871bis-01. What do you think? -Julian signature.asc Description: This is a digitally signed message part. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hector Santos wrote: I would not be surprised if testing this with gmail.com shows the same thing which the online gmail MUA will have an indicator: signed by: some signer domain but will it display the injected spoofed unbounded 5322.From? For the records, from my gmail testing, it will spambox the RFC 5322 message with one or more 5322 lines. But it also does one other thing - it removes ALL the headers and recreates its own with no subject. It doesn't matter if its signed or not. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
Julian Mehnle wrote: Hector Santos wrote: Right. Does this add signer reputation weight for the injected 5322.From? Probably not. How do you know what the heuristic systems are doing? AFAICT mipassoc.org doesn't verify DKIM sigs on list messages, it does. It verifies, adds an Authentication-Results: header, strip the original signature, add a fooder and a [list] to the subject and resigns. and even if it did, a verified DKIM sig (such as one created by the original author of the message) doesn't tell anything about the legitimacy of the use of the From identity. Not sure what that means Julian. Personally, -1 on suggesting a h=from:from, because you are assuming that operators are actually defining a h= tag. If its blank, its falls back to the semantics written - use the LAST header found. No. h= must not be empty. The spec explicitly forbids this. You misunderstood. What that means is that the signing function MUST add a h= to the 5322.DKIM-Signature line for the 5322.headers it decides to hash and bind to the signature. The operators with their DKIM implementation can set what headers to sign or they can choose NOTHING and allow the default behavior for the implementation. In other words, the operator can set (in whatever way the software does it): RequiredHeaders From:To:Date:Message-Id:Organization:Subject Now the signing engine will follow this. If not set, then it has its own default rules. The recommendation is presented in RFC 4871. What you are suggestion is that implementation had their defautlt to include From:From, like above: RequiredHeaders From:From:To:Date:Message-Id:Organization:Subject As for a possible change in RFC 4871bis, if you look at page 41 of 4871bis-01 (page 36 in RFC 4871), it already has this nice little note: | INFORMATIVE NOTE: A header field name need only be listed once | more than the actual number of that header field in a message at | the time of signing in order to prevent any further additions. | For example, if there is a single Comments header field at the | time of signing, listing Comments twice in the h= tag is | sufficient to prevent any number of Comments header fields from | being appended; it is not necessary (but is legal) to list | Comments three or more times in the h= tag. I suggest replacing Comments with From. That should solve the problem. I did notice this too and thought the same idea. :) What the specs need in whatever IETF method you guys like to do things: 1) Semantics that DKIM-compliant MTA doing stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. 3) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. -- 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. One could argue that this'd be a material change to the protocol that is not a deletion, and hence that deployed code would have to change to comply, which, to me, goes against at least the spirit of the PS-DS transition. (Which is the point of the current exercise.) So in terms of meeting our chartered goals, this specific addition might have undesirable side effects were it to represent the WG's opinion. (Much as the chairs love you all, starting right in on a 4871ter is not attractive:-) Stephen. PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Stephen Farrell wrote: On 05/10/10 23:54, Julian Mehnle wrote: Recommending that one more From be added to h= (and hashed) than From headers are initially placed in the message should be enough. There is no need to change the semantics of the spec. Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. So in terms of meeting our chartered goals, this specific addition might have undesirable side effects were it to represent the WG's opinion. (Much as the chairs love you all, starting right in on a 4871ter is not attractive:-) To address current implementations, guidelines should be considered: 1) Suggest MTA do stonger RFC 5322 checking and at a minimum, checking for multiple 5322.From (and possible even 5322.Subject). 2) To close the loophole to #1 (legacy software), the DKIM signer MAY consider adding a h=from:from to the DKIM-Signature. 3) To close the loophole to #1 (legacy software), the DKIM verifier SHOULD void messages with 5322.From which are not bound to the signature. #1 is words and a remember for MTA especially those that are with a DKIM environment to tighten up there wares. #2 can be done with current implementation operators. I am assuming all or not most of DKIM signing engines will allow operators to set Required Headers to sign. It would be rather inflexible if it did not. #3 is already done by at least one open source DKIM API developed by a large MTA vendor. Not sure how OpenDKIM is will do it, but Murray did speak of the layer (#1) approach. #1 and #2 will allow most implementations to close this loophole until software vendors catch up with #3. That said, I don't think writing #1, #2 or #3 text for 4871bis should slow down progress to draft standard. -- HLS ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. FWIW: Adding to a specification, by trying to protect against behavior that is already illegal is wasteful, redundant and opens the door to an infinite path of similarly unnecessary provisions. Plainly bad specification methodology. 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] THIS IS A MULTIPLE 5322.FROM MESSAGE
On Tue, Oct 05, 2010 at 10:31:32PM -0400, Dave CROCKER allegedly wrote: PS: Note that I'm saying nothing about whether or not this issue should be mentioned in 4871bis. FWIW: Adding to a specification, by trying to protect against behavior that is already illegal is wasteful, redundant and opens the door to an infinite path of similarly unnecessary provisions. Plainly bad specification methodology. Right. This seems like it's going down a rat-hole. There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Mark Delany Sent: Tuesday, October 05, 2010 8:06 PM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE There was an assertion in RFC4780 about conforming emails that must only have a single 2822.From header. That got lost in the translation to 4781 I guess. Unfortunately, 4780 failed to specify what conforming means explicitly. I also know that this WG has repeatedly stated that messages that are not within standard MUST fail verification. That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
Hi Stephen, At 16:46 05-10-10, Stephen Farrell wrote: Assuming that recommending above maps to a (putative) MUST/SHOULD statement in 4871bis, I'd be interested in opinions as to whether such a change might slow progress to draft standard, or be detrimental to current deployments. Such a change may affect the progress to draft standard. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] THIS IS A MULTIPLE 5322.FROM MESSAGE
That this is not in 4871 seems to be mostly a WG assumption that should be made explicit. I think several of us thought it was in there, but on review it apparently was indeed lost somewhere along the way. We've certainly, as I understand it, been proceeding from that assumption for a very long time. I like the idea of saying so explicitly in 4871bis, and applying it both to signers and to verifiers. Agreed. Though frankly I couldn't care less about signers. It's always the verifier that really counts. I don't like the idea of being any more specific than that. That is, I don't want to create specific text for specific cases we know about because that means anything we don't list could be perceived as less critical. A blanket admonishment to implementers is sufficient and appropriate. Right. We could attempt to enumerate the 1,000 edge-cases we know today and then re-bis 4871 for the additional 1,000 edge-cases we learn tomorrow, or we could simply say that invalid 2822 messages MUST never verify and call it a day. Mark. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
