[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] Necessary Verifier Actions to mitigate exploitation of trust established through DKIM signatures.
On Fri, 05 Nov 2010 18:46:37 -, Douglas Otis do...@mail-abuse.org wrote: Append to Section 6 Verifier Actions: It is not reasonable to assume a message is in compliance with RFC5322. To mitigate trivial exploitation of trust established by DKIM signatures, messages having multiple header fields for orig-date, from, sender, reply-to, to, cc, message-id, in-reply-to, references, or subject MUST always return PERMFAIL for any DKIM signature associated with the message. When there are multiple singleton header fields, a field selected for display or sorting is therefore undefined. Likely top-down selections by consumers of DKIM status where the signature verification selects bottom-up leaves singleton headers highly prone to trivial exploitation. +0.75 I prefer requiring the signer to make such a check and then verifying that the signer had done so. It comes to the same thing, of course (it establishes that no extra headers had appeared in between, or alternatively that no malicious signer had failed to make the check). See wording proposed by Hector and myself. The benefit of this approach is that we avoid accusations ot layer violations. Note also that it is also sufficient to address only this header counting violation of 5322. If any other 5322 violation is present (e.g. a malformed header, which might be part of some scam) then, assuming that header has been signed, the evidence of the malformation will be preserved and its effect will be the same as if such a scam were attempted with current unsigned messages. 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] FW: New Version Notification for draft-kucherawy-authres-vbr-00
On 08/Nov/10 06:25, Murray S. Kucherawy wrote: Filename: draft-kucherawy-authres-vbr Revision: 00 Title: Authentication-Results Registration For Vouch By Reference Results Creation_date: 2010-11-07 WG ID: Independent Submission Number_of_pages: 7 Abstract: This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. Nice one, Murray! Section 4 (Definition) is ambiguous, though. It says the DNS domain name used to perform the VBR query, but a VBR query takes two domain names. I think mentioning the tag (md, according to the example) would make it clearer. However, why not structure all the available domains? E.g. delivering something like (modified from section A.1) Authentication-Results: mail-router.example.net; dkim=pass (good signature) header.d=newyork.example.com header.b=oINEO8hg; vbr=pass (all) header.mv=voucher.example.net header.md=newyork.example.com where the comment contains the actual content of the TXT record. A machine readable voucher name could be used by clients to learn what vouchers a server trusts. Another item that may need clarification is the positive response given in the definitions of pass and fail. It could be expanded as, say, pass: A VBR query was completed and the vouching service queried gave a positive response. That is to say, it returned a record consisting of strings of lowercase letters separated by spaces, as per section 5 of [VBR]. The added sentence is meant to dispel any question on whether the verifier should attempt to match the text in the RR with the content of the mc= tag in the VBR-Info header field, if any. ___ 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
[ietf-dkim] I-D Action:draft-ietf-dkim-implementation-report-04.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Keys Identified Mail Working Group of the IETF. Title : RFC4871 Implementation Report Author(s) : M. Kucherawy Filename: draft-ietf-dkim-implementation-report-04.txt Pages : 17 Date: 2010-11-07 This document contains an implementation report for the IESG covering DomainKeys Identified Mail (DKIM) in support of the advancement of that specification along the Standards Track. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ftp://ftp.ietf.org/internet-drafts/draft-ietf-dkim-implementation-report-04.txt ___ 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
