Re: [ietf-dkim] Getting resolution on the double header issue
On Thu, 11 Nov 2010 17:55:55 -, Douglas Otis do...@mail-abuse.org wrote: Once one DKIM verification vendor includes these necessary checks that suppress DKIM PASS, and another vendor does not, DKIM implementations are no longer compatible. IMHO, this represents a DKIM protocol failure to properly define elements that MUST BE checked to qualify a DKIM PASS verification result. The DKIM protocol may require future updates as new exploits are discovered, or a significant design goal will have been lost. Actually, for the particular problem we are considering, this will not arise. In the scheme I have proposed, the Signer MUST do X and the Verifier MUST check that the Signer had done X. However, X only arises where there are multiple once-only headers (so the message is already 5322 incompatible). So even if the (old) signer fails (to sign both in this case), the (new) verifier is then merely rejecting a message that was 5322-incompatible anyway, which is no big deal. -- 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] Getting resolution on the double header issue
On Mon, 08 Nov 2010 09:20:19 -, Barry Leiba barryle...@computer.org wrote: I have a chair statement to start with, and then the rest of this message will be as a participant. As chair: We have gone off in the weeds on the double header issue, and are fighting with ourselves. The chairs need everyone to aim at getting some rough consensus on this, so we're asking this: let's focus, as we once did, on working together to achieve a result that most of us, at least, can live with. That means that many people will not get it just the way they want it, and you might not see a result that you consider ideal. I think we're close enough, really, on this that we can still get a result that we consider acceptable. OK. Here is a suggestion. I think it is broadly in line with your proposal, but it includes various almost-orthogonal parameters that can be tweaked independently of each other to provide a final version. Word-smithing can come later, and it will also need NOTEs and Security Considerations to explain the problem(s) and how they are covered. But be clear that this is an unashamedly Normative proposal. 1. Framework: o Signers MUST/SHOULD do something (see below) in the event that the message contains multiple once-only headers. PLUS Verifiers MUST/SHOULD check that something had been correctly applied (else PERMFAIL). Note that this will catch both headers maliciously added in transit/replay and malicious signers. o As above, but covering other RFC 5322 violations as well as once-only headers. 2. Normativeness: o MUST o SHOULD 3. Definintion of something o Refuse to sign (i.e. reject) if multiple once-only found [or other 5322 violations]. I had a wording for this. o Permit signing of multiple once-only (even though violating 5322), but require ALL those headers to be signed (i.e. included in 'h=' tag). Hector has a wording for this. 4. Scope of something o Apply the above to ALL multiple once-only headers found. o Apply the above only to those headers actually mentioned in the 'h=' tag. (e.g. allow multiple Subject:s if Subject entirely absent from 'h='.) 5. Definition of once-only o Just the From: header o All headers defined as once-only in RFC 5322. o As above, but include RFC 2045 o As above, but include at least some List-* headers o Other, please specify I count the permutations of those as leading to 80 different proposals, though I suspect some of them are not meaningful. But they cover most of the normative-style proposals that have been made during the dicussion. And note that there are no layering violations (since the one protocol simply introduces a requirement to be applied at one stage and checked at another). -- 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] Getting resolution on the double header issue
rfc4871bis-02 Introduction: ,--- ... DKIM: o is compatible with the existing email infrastructure and transparent to the fullest extent possible; o requires minimal new infrastructure; o can be implemented independently of clients in order to reduce deployment time; o can be deployed incrementally; o allows delegation of signing to third parties. ... '--- DKIM establishes additional trust based upon a signature's domain, where DKIM MUST protect use of this trust without assuming changes will be made to existing email infrastructure. Some have suggested new mail-filtering should be added to MUAs, MTAs, and other mail agents to prevent exploits of DKIM trust allowed by DKIM's verification having neglected essential checks for multiple singleton header fields. Once one DKIM verification vendor includes these necessary checks that suppress DKIM PASS, and another vendor does not, DKIM implementations are no longer compatible. IMHO, this represents a DKIM protocol failure to properly define elements that MUST BE checked to qualify a DKIM PASS verification result. The DKIM protocol may require future updates as new exploits are discovered, or a significant design goal will have been lost. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 09/Nov/10 03:05, John R. Levine wrote: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. This is OK, but it misses the scenario where a bad guy takes an existing signed message and prepends another Subject: or From: header. It's more effective to address this in the verifier. I'd agree on the effectiveness of that approach from a software design POV only. Designing specifications may involve different considerations... 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. I don't feel strongly about how normative we make the language, but I do think it would be a good idea to encourage verifiers not to say the signature is valid on a message with extra headers, even if it mechanically verifies. This catches both the sloppy signer and the hostile intermediary. FWIW, my DKIM verifier has for several weeks rejected anything which has an extra of any of these [omitted] headers: Thanks for putting it that way, John. It makes it easier to clear the issue: I think everybody agrees that DKIM specifications say nothing about rejecting. Therefore, John's software is called a DKIM verifier somewhat improperly. It /includes/ a DKIM verifier, but also acts as a band-pass message filter. IMHO, strong feelings about this issue come up from misunderstandings about these roles. On the one hand we have a normative definition of the mechanical properties of signatures. On the other hand we want to deal with MTA behavior, since that is the mechanism's semantics. One problem of tackling both topics within the same document is that making normative statements about MTA behavior may result in confusion between semantic validation and mechanical verification. At this point I would rephrase the third paragraph of Murray's Take two for 8.14 Malformed Inputs, as follows: Because of this, DKIM implementations for MTAs are strongly advised to couple with message filters who can complement their MTA's native checks and reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature validates according to normative DKIM specification. However, referring to another document --either ADSPbis or draft-kucherawy-mta-malformed-- may allow for stronger and clearer language. For example, setting dkim=fraud in an A-R field would not be confused with broken signatures like dkim=fail (technically pass). ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On Mon, Nov 8, 2010 at 6:05 PM, John R. Levine jo...@iecc.com wrote: FWIW, my DKIM verifier has for several weeks rejected anything which has an extra of any of these headers: From Sender Subject Date To Cc MIME-Version Content-Type Content-Transfer-Encoding I haven't collected detailed statistics, but I can report that nothing horrible has happened. I have an exim system that I've enforced rfc5322 on for a few days now. I quarantine, but still deliver as well (for now). So far I've seen emails from the following well known sources that failed this test. 1. bill...@ebay.com (multiple To, one is blank) 2. bill...@ebay.com.au (same as #1) 3. University of Montana tuition bill (multiple To) 4. sendmail DSN's from my own sendmail system (multiple To) (ok, not well known, but I'm the source and I'm aware of it) It's Mail::DKIM, the changes are about eight lines. Anyone else wants it, just ask. I'd be interested in that. -- Regards... Todd I seek the truth...it is only persistence in self-delusion and ignorance that does harm. -- Marcus Aurealius ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
FWIW, my DKIM verifier has for several weeks rejected anything which has an extra of any of these [omitted] headers: Thanks for putting it that way, John. It makes it easier to clear the issue: I think everybody agrees that DKIM specifications say nothing about rejecting. Therefore, John's software is called a DKIM verifier somewhat improperly. It /includes/ a DKIM verifier, but also acts as a band-pass message filter. Um, no. When I said DKIM verifier I meant DKIM verifier. Please avoid speculating when you could just ask. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Getting resolution on the double header issue
I have a chair statement to start with, and then the rest of this message will be as a participant. As chair: We have gone off in the weeds on the double header issue, and are fighting with ourselves. The chairs need everyone to aim at getting some rough consensus on this, so we're asking this: let's focus, as we once did, on working together to achieve a result that most of us, at least, can live with. That means that many people will not get it just the way they want it, and you might not see a result that you consider ideal. I think we're close enough, really, on this that we can still get a result that we consider acceptable. Because we're in the middle of the IETF meeting, some of us -- including the chairs -- are very busy this week. Let's set a deadline of 24 November, and say that by that date we will have an answer that has rough consensus. Please, folks, give and take, and work together to reach that. As a side issue, I would like the 4871bis editors to post a message by that same date summarizing the other open issues with 4871bis, and their assessment of the current consensus state of them. We would still like to get the issues resolved and get 4871bis to the IESG in December, probably for the 16 Dec telechat. As participant: Here's how I see the situation. It's purely as a participant, and has no chair weight. I think it does represent a compromise position that should work. Problem description: An attack has been described that can be mounted by adding a second from, subject, or possible other header field that is only supposed to appear once. This situation might fool a UA, filtering software, or some other software into considering the added, unsigned field as the real one. Who is responsible for dealing with this situation? If the DKIM spec is at least partially responsible, to what extent, and what should it say? Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 08/Nov/10 10:20, Barry Leiba wrote: As participant: [...] Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. +1. IMHO, 8.14 may avoid giving any advice, if we are unable to agree on any. However, in such case, I'd recommend to take Julian's suggestion[1] of replacing Comments with From in the note that exemplifies the ugly hack. [1] http://mipassoc.org/pipermail/ietf-dkim/2010q4/014683.html 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. Perhaps this is an issue about MTA configuration, rather than specifically for the signing module. For example, I'm quite happy that such tweaking occurs before signing, so that the signer signs the revised version. However, since also the verifying filter is invoked after any optional modifications, I've had to enable them for MSA only. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. This is again a question of roles. John has (correctly) recommended that verifiers don't tamper with the message content, except for possibly adding an A-R field. However, a DKIM verifier does not /have/ to act as a verifier only. An additional role is the umbrella under which a filter module may discard suspicious messages, suppress unsigned singleton fields that occur more than once, or anything it deems cool. I agree it should be informative, w.r.t. DKIM. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
works for me (to the mailing list this time) On Nov 8, 2010, at 4:20 AM, Barry Leiba wrote: I have a chair statement to start with, and then the rest of this message will be as a participant. As chair: We have gone off in the weeds on the double header issue, and are fighting with ourselves. The chairs need everyone to aim at getting some rough consensus on this, so we're asking this: let's focus, as we once did, on working together to achieve a result that most of us, at least, can live with. That means that many people will not get it just the way they want it, and you might not see a result that you consider ideal. I think we're close enough, really, on this that we can still get a result that we consider acceptable. Because we're in the middle of the IETF meeting, some of us -- including the chairs -- are very busy this week. Let's set a deadline of 24 November, and say that by that date we will have an answer that has rough consensus. Please, folks, give and take, and work together to reach that. As a side issue, I would like the 4871bis editors to post a message by that same date summarizing the other open issues with 4871bis, and their assessment of the current consensus state of them. We would still like to get the issues resolved and get 4871bis to the IESG in December, probably for the 16 Dec telechat. As participant: Here's how I see the situation. It's purely as a participant, and has no chair weight. I think it does represent a compromise position that should work. Problem description: An attack has been described that can be mounted by adding a second from, subject, or possible other header field that is only supposed to appear once. This situation might fool a UA, filtering software, or some other software into considering the added, unsigned field as the real one. Who is responsible for dealing with this situation? If the DKIM spec is at least partially responsible, to what extent, and what should it say? Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. Barry ___ 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] Getting resolution on the double header issue
Barry Leiba wrote: Who is responsible for dealing with this situation? If the DKIM spec is at least partially responsible, to what extent, and what should it say? Whether we have the guts to do what is correct as oppose of trying to work it in due to IETF meeting mile stones and time deadlines, is entirely different issue. IMO, DKIM is responsible for the input that are part of is formula. Parts it MUST make sure are RFC5322 correct for consumption with its purported trust signature, especially its sole single input header requirement, 5322.From. Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. Who's version? 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. +1 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1 I believe I provided good text with the original ISSUE posting I made and also modifications along the threads. This focus mainly with following up with the logic for the last header begins in Section 5.4 and where the corrective text should be made. Its a do this , but keep in mind that semantic. Overall I prefer to see an updated specification that will help developers write software consider options to deal with this correctness issue directly and independently from another protocol logic. IMO, this is the proper Software Engineering approach to maximize a fix across all MTA of all kinds. I prefer not to read text that tries to pass the buck, push the burden on to MTAs or MUAs solely. That will minimize the adoption rate because they could be legitimate MTAs that are not capable to satisfy the outside RFC5322 correctness requirement or mandate in order for DKIM to provide workable results. At the end of the day, I believe that it is major goal to get ALL DKIM software to work with the same expectation here and not get into situations in the future where there are deviations. It MUST become a mandate in order to build the initial trust required for DKIM. -- 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] Getting resolution on the double header issue
Alessandro Vesely wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. But DKIM can not make that presumption that is the prevailing nature of many MTAs. At best, it can RECOMMEND that integration DKIM into a mail system that for BEST results, a general filter would address this issue. But it can't assume that will be possible as it might mean a software change. Hence the better DKIM software will offer a direct solution that COULD be turned off when the MTA is capable of doing the filter itself. For example, OpenDKIM is a package mainly for the Sendmail MTA. It may have or will have a MTA milter to check for RFC 5322 compliance. However, the I believe the software also allows has a DKIM only component that can be used in other MTAs. You don't know if these other MTAs will have the same kind of filter DKIM is expecting in order to have clean results. Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has an non-overhead DKIM verifier option that deals this multiple 5322.From issue directly and independently from any other layered requirement. To me, the latter is the best approach for the specification to take. Allow Readers of this document to decide how they will implement DKIM based on the MTA they are using or MTAs they are targeting. Perhaps this is an issue about MTA configuration, rather than specifically for the signing module. Which is just as equal of saying MTAs may or may having RFC5322 compliance checking. DKIM can not be dependent for providing valid results only when working with MTA that have RFC5322 compliance checking. For example, I'm quite happy that such tweaking occurs before signing, so that the signer signs the revised version. Tampering with mail is not justified here. Either the mail is good to sign or bad to sign when it comes to DKIM signing. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. This is again a question of roles. John has (correctly) recommended that verifiers don't tamper with the message content, except for possibly adding an A-R field. However, a DKIM verifier does not /have/ to act as a verifier only. An additional role is the umbrella under which a filter module may discard suspicious messages, suppress unsigned singleton fields that occur more than once, or anything it deems cool. Generally, the caller of the DKIM procedure would act on its results. I prefer to see a blackbox model for DKIM where its interface points are well defined. Its input was well described with stated boundary conditions and its output is well defined and described with a view on being a feed for possible message filters/handlers. -- Sincerely Hector Santos http://www.santronics.com -- 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] Getting resolution on the double header issue
On Monday, November 08, 2010 04:20:19 am Barry Leiba wrote: As participant: Here's how I see the situation. It's purely as a participant, and has no chair weight. I think it does represent a compromise position that should work. Problem description: An attack has been described that can be mounted by adding a second from, subject, or possible other header field that is only supposed to appear once. This situation might fool a UA, filtering software, or some other software into considering the added, unsigned field as the real one. Who is responsible for dealing with this situation? If the DKIM spec is at least partially responsible, to what extent, and what should it say? Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. I think this oversimplifies the issue from a DKIM perspective. If this were added, should signatures that sign a second (non-existant) from header specifically to ensure header addition breaks the signature verification be verified if in fact the message hasn't been modified? Rather than fall back purely on 5322, I'd prefer to see something in security considerations that says if the count of a particular header field that is supposed to be limited (e.g. From and Subject) present in a message exceeds the number of signed fields, then the signature shouldn't be verified. Additionally, signing a message with (for example) two From: fields is not a problem in the context of this issue, so the advice not to sign such messages isn't particularly related. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On 08/Nov/10 15:52, Hector Santos wrote: Alessandro Vesely wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1. Enforcing some RFC conformance is a task that many MTAs can (optionally) do natively. But DKIM can not make that presumption that is the prevailing nature of many MTAs. At best, it can RECOMMEND that integration DKIM into a mail system that for BEST results, a general filter would address this issue. Yes. If there will ever be an MTA considerations appendix, it may prompt MTA developers to provide for filtering callbacks at the right points. But it can't assume that will be possible as it might mean a software change. Hence the better DKIM software will offer a direct solution that COULD be turned off when the MTA is capable of doing the filter itself. Anything we change in the protocol may imply software changes. For example, OpenDKIM is a package mainly for the Sendmail MTA. It may have or will have a MTA milter to check for RFC 5322 compliance. However, the I believe the software also allows has a DKIM only component that can be used in other MTAs. You don't know if these other MTAs will have the same kind of filter DKIM is expecting in order to have clean results. Yes, the library component of OpenDKIM provides for just DKIM (well, it also has some generic utilities, e.g. for parsing mailboxes.) It works equally well with different MTAs as offline. Now take Alt-N pure C/C++ DKIM API with no tie-ins to any MTA. It has an non-overhead DKIM verifier option that deals this multiple 5322.From issue directly and independently from any other layered requirement. However, that feature makes for more difficult usage. It tells the caller that a given signature failed to verify by delivering a status of DKIM_UNSIGNED_FROM. Now, suppose the caller is a forensic tool, rather than an MTA filter. The tool is interested in knowing whether the signature validates, but it cannot be sure that the reported status was the /only/ problem with that signature. In facts, it'd be better off disabling such verifier option. (And it can be disabled because it is not mandated.) Now for MTA message filters. Why should a DKIM library hide the simple facts and opt for telling them what to do instead? It is quite trivial to count the From fields in the header. A library can provide a function that tells whether a given field was signed by a given signature. Based on such simple facts, a filter may make various decisions. It may turn out that an unsigned From deserves the same treatment as a failed signature, but are we sure that that is the only one option whatever the circumstances? Actually, we haven't observed many occurrences of that attack in the wild. To me, the latter is the best approach for the specification to take. Allow Readers of this document to decide how they will implement DKIM based on the MTA they are using or MTAs they are targeting. However, if that behavior were mandated, it would affect all compliant libraries, forensic tools notwithstanding. I prefer to see a blackbox model for DKIM where its interface points are well defined. Its input was well described with stated boundary conditions and its output is well defined and described with a view on being a feed for possible message filters/handlers. +1. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Barry Leiba Sent: Monday, November 08, 2010 1:20 AM To: IETF DKIM WG Subject: [ietf-dkim] Getting resolution on the double header issue Proposal: 1. The DKIM spec is responsible for describing the problem in terms of how it relates to signed and unsigned versions of the fields. That's the stuff in 8.14. Concur. I worked through an 8.14 proposal a couple of weeks ago using input from the list. The last text I have was: 8.14 Malformed Inputs DKIM allows additional header fields to be added to a signed message without breaking the signature. This tolerance can be abused, e.g. in a replay attack, by adding additional instances of header fields that are displayed to the end user or used as filtering input, 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]. The way such input will be handled and displayed by an MUA is unpredictable, but in some cases it will display the newly added header fields rather than those that are part of the originally signed message alongside some valid DKIM signature annotation. This might allow an attacker to replay a previously sent, signed message with a different Subject, From or To field. Because of this, DKIM implementers are strongly advised to reject or treat as suspicious any message that has multiple copies of header fields that are disallowed by section 3.6 of [MAIL], particularly those that are typically displayed to end users (From, To, Cc, Subject). A signing module could return an error rather than generate a signature; a verifying module might return a syntax error code or arrange not to return a positive result even if the signature technically validates. Senders concerned that their messages might be particularly vulnerable to this sort of attack and who do not wish to rely on receiver filtering of invalid messages can ensure that adding additional header fields will break the DKIM signature by including two copies of the header fields about which they are concerned in the signature (e.g. h= ... from:from:to:to:subject:subject ...). See Sections 3.5 and 5.4 for further discussion of this mechanism. Specific validity rules for all known header fields can be gleaned from the IANA Permanent Header Field Registry and the reference documents it identifies. 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. Works for me. How about: 3.10. Input Requirements DKIM's design is predicated on valid input. Therefore, signers and verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to [MAIL], [MIME], and any other relevant message format standards. See Section 8.14 for additional discussion and references. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. Yup; the above two amendments cover both cases. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
-Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Alessandro Vesely Sent: Monday, November 08, 2010 9:28 AM To: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Getting resolution on the double header issue Yes. If there will ever be an MTA considerations appendix, it may prompt MTA developers to provide for filtering callbacks at the right points. Two points about that: 1) The proposed 8.14 does bring up some MTA considerations relevant to the issue we've been discussing. 2) I just introduced a draft intended to become a place to collect discussion about how best to handle common malformations, and this could include the case we've been discussing. It's intended to get BCP status, but I don't think we want to work on it in this working group. (draft-kucherawy-mta-malformed if anyone wants to provide feedback.) Yes, the library component of OpenDKIM provides for just DKIM (well, it also has some generic utilities, e.g. for parsing mailboxes.) It works equally well with different MTAs as offline. Just to be precise: OpenDKIM includes a filter that uses the milter protocol to talk to MTAs, but is not mainly for any one MTA. Postfix and Oracle's MTA (formerly Sun JMS) can both use it as well since they have adopted milter. But it also includes a library that is completely MTA agnostic, and in fact is in use in production at AOL and Yahoo with whatever MTAs they're using there. The filter already does the RFC5322 checking, but the library currently doesn't (apart from erroring out if the input message doesn't contain a From field, since RFC4871 needs that). It's deliberately a pretty pure partition wherever possible. However, I have opened an RFE to add the more thorough checking as an option to the library in case a filter developer doesn't want to bother but is concerned about this issue. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
On Nov 8, 2010, at 1:20 AM, Barry Leiba wrote: 2. The DKIM spec should probably say that signers need to sign valid messages, and, therefore, SHOULD NOT sign things like this. Text along the line of this might work well: Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. +1 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. Seems unnecessary per #2 above, but I don't care all that much either way. 4. We should agree to this or some variant of it, and then move on. This is not meant to satisfy everyone. In fact, it isn't what I'd prefer, if I had my full choice. But it takes care of the problem in a way that I think is sufficient, and allows us to resolve the issue. +1 On Nov 8, 2010, at 7:52 AM, Scott Kitterman wrote: Rather than fall back purely on 5322, I'd prefer to see something in security considerations that says if the count of a particular header field that is supposed to be limited (e.g. From and Subject) present in a message exceeds the number of signed fields, then the signature shouldn't be verified. I'd have no objection to this either. At this point the only strong objection I'd have would be if the consensus measurement were based on one or two people repeatedly expressing Very Strong Feelings while the rest (like me) mostly don't care. A meh result is not the same as a yes or no. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Getting resolution on the double header issue
Signers SHOULD take reasonable steps to ensure that the messages they're signing are valid according to [RFC 5322, etc]. Leaving the definition of reasonable out allows flexibility. It may be waffly, but I like the approach in this case. This is OK, but it misses the scenario where a bad guy takes an existing signed message and prepends another Subject: or From: header. It's more effective to address this in the verifier. 3. It'd be reasonable for the DKIM spec to remind verifiers that signers aren't supposed to sign stuff like this, so they might consider that when deciding what to do with it after verification. It'd be reasonable to remind them of this particular case. But I think that all ought to be informative text. I don't feel strongly about how normative we make the language, but I do think it would be a good idea to encourage verifiers not to say the signature is valid on a message with extra headers, even if it mechanically verifies. This catches both the sloppy signer and the hostile intermediary. FWIW, my DKIM verifier has for several weeks rejected anything which has an extra of any of these headers: From Sender Subject Date To Cc MIME-Version Content-Type Content-Transfer-Encoding I haven't collected detailed statistics, but I can report that nothing horrible has happened. It's Mail::DKIM, the changes are about eight lines. Anyone else wants it, just ask. 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