Re: [ietf-dkim] New canonicalizations
On Mon, 23 May 2011 03:50:06 +0100, Hector Santos hsan...@isdg.net wrote: Case in point. Right now, I am looking at a gmail.com which I am pretty sure was not in Base64 MIME. However, it was submitted to IETF DISCUSS group and its showing up as base64 MIME. I don't know if the list did it one of the hops before the DKIM-Signature. But the body hash failed. So I took the message, made a copy and unbased64 the body, pulled the list footer and poof! - the body hash was ok again. It would of been nice to have some DKIM-Signature flag that might indicate the Content-Transfer-Encoding, i.e.: et=base64 --- copy of the top level Content-Transfer-Encoding Could you get the effect of this by including the Content-Transfer-Encoding header in the 'h=' and doing some fancy checks involving the 'bh=' (to detect whether it was the body or the headers or both that were broken)? -- Charles H. Lindsey -At Home, doing my own thing Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: c...@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] New canonicalizations
On 19 May 2011, at 18:19, Murray S. Kucherawy wrote: -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Ian Eiloart Sent: Thursday, May 19, 2011 3:21 AM To: John Levine Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] New canonicalizations Probably true, but if the difference between 10% broken and 8% broken signatures is independent of whether the email is spam, then actually relaxed seems to be producing a 20% reduction in signature breakage. I'd argue that a 20% reduction in broken signatures *is* actually much better. That statistic is largely meaningless unless there's a basis for comparison. For example, it would be useful to observe that the same message, sent with each of the four canonicalizations, to the same set of destinations using the same endpoint software, produced different results given that one changing variable. But if domain X only ever tried sending with relaxed/relaxed and generally gets good results, there's nothing in that datum to say that simple/simple would not have worked just as well for the same sender with the same mail. Thus I don't believe there's enough data to support your conclusion. Well, nor do I really. I'm just pointing out that IF IF IF the 10% and 8% figures are real then it's the 10% and 8% that you need to be comparing (that's a 20% improvement) not the 90% and 92% (a trivial improvement). However, someone else pointed out that spammers and non-spammers seem to have similar patterns of using simple and relaxed. If that's the case, then we've eliminated one potential problem with the data. That relaxed/relaxed appears to survive 20% more might be based on the fact that the people using it send clean mail through clean paths, and it's as simple as that. True. Though I've found that maybe one third of messages that I see with a bad signature also carry a good signature. To determine that, we'd need a pareto analysis of breakage modes. Presumably lists that aren't re-signing are responsible for some of this, as are broken signing mechanisms. The questions remaining are, is there anything left after excluding those two cases?, and how much of that could be fixed easily?. Our stats are unable to tell what the problem is in all cases, but for mail we've received where the signer used the z= tag, the biggest signature breaker in terms of header changes is modified To: fields. I suspect that's either rewriting by lists to add the list description as a comment, or improperly quoted comment fields that are corrected along the way. For May, so far, I see these canonicalisations for good signatures: 206136 c=relaxed/relaxed 55748 c=relaxed/simple 1 c=simple/relaxed 29207 c=simple/simple I also see these problems: 5816 invalid - public key record (currently?) unavailable 364 signing domains 3772 invalid - syntax error in public key record 93 signing domains And these for bad signatures: 22577 c=relaxed/relaxed (9.9%) but 6087 (27%) of these are from yahoogroups.com, and almost all also carry a good signature! 4065 c=relaxed/simple (6.7%) 6 c=simple/relaxed 3094 c=simple/simple (9.6%) And these are the failure reasons: simple/simple: 1992 body hash mismatch (body probably modified in transit)] 1102 signature did not verify (headers probably modified in transit)] relaxed/simple: 2796 body hash mismatch (body probably modified in transit)] 1269 signature did not verify (headers probably modified in transit)] relaxed/relaxed: 1824 body hash mismatch (body probably modified in transit)] 20753 signature did not verify (headers probably modified in transit)] d=yahoogroups.com: 9 body hash mismatch (body probably modified in transit)] 5949 signature did not verify (headers probably modified in transit)] -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 19 May 2011, at 22:53, Pete Resnick wrote: In RFC 2119 (the document that defines MUST, SHOULD, etc.), MUST does not mean vitally important and SHOULD does not mean really really important, but less important than MUST. MUST means you have to do this or you're not going to interoperate. SHOULD means, there are ways to not do this which will still interoperate, but you had better know what those ways are and you better be sure to do them, and if you don't, then you MUST NOT do this. That is, SHOULD is equivalent to MUST unless you know exactly what you are doing. In this case, the spec says that you MUST downgrade prior to signing *unless you know that the end-to-end path is 8-bit clean and will not downgrade later*. That's what SHOULD downgrade means. If there is an implementation that doesn't downgrade and sends a message without knowing that the path is end-to-end 8-bit clean, then it is in violation of the spec. Changing it to MUST doesn't change anything for such an implementation; it is already in full violation. Downgrading is undesirable, especially given the increasing popularity of mobile clients. In theory, the signature could be added at SMTP time, with downgrading occurring dependent upon whether 8bitmime is advertised by the recipient's MTA. Of course, there's a risk that the message will then require downgrading when forwarded by the recipient's MTA, but that risk should decrease with time (for example, Exim's developers have 8bitmime development as a priority now). And, it's also an option for the recipient's MTA to add a new signature (whatever that's worth). -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 20 May 2011, at 05:24, Hector Santos wrote: In this case, if this is enforced with a MUST, for a system that is not 8BITMIME ready but is adding DKIM signing support, to remain compliant it is far more feasible to add a rule to a DKIM signing component: If mail is 8bit then SKIP signing. But why skip? Usually the message won't be downgraded. And even if they are, usually a broken signature will cause no harm. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Could you get the effect of this by including the Content-Transfer-Encoding header in the 'h=' and doing some fancy checks involving the 'bh=' (to detect whether it was the body or the headers or both that were broken)? No, of course not. The bh= and h= are just hashes, so all they can tell you is whether the text being hash has changed, not how the body has changed or which header changed. There's no separate hash for individual header lines. On the other hand, you might want to look at page 24 of RFC 4871. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Charles Lindsey wrote: On Mon, 23 May 2011 03:50:06 +0100, Hector Santos hsan...@isdg.net wrote: It would of been nice to have some DKIM-Signature flag that might indicate the Content-Transfer-Encoding, i.e.: et=base64 --- copy of the top level Content-Transfer-Encoding Could you get the effect of this by including the Content-Transfer-Encoding header in the 'h=' and doing some fancy checks involving the 'bh=' (to detect whether it was the body or the headers or both that were broken)? Using the currently defined standard specification, the only way to do a reliable check is to add the z= header which contains the values of the h= header fields. However, having z= is more for testing, can be exploited in some fashion and adds ugly DKIM-Signature bandwidth overhead. So its not a good idea, I think, for everyday usage. But since DKIM is flexible :), adding maybe an et= tag should not break the system allowing for exploration to see if that could help lower failures for some streams. In this test case with the gmail.com message submitted to a non-DKIM aware list, it would of succeeded knowing the original top level encoding type and using l= if destined to a list. I think the other side point in my OP, is that it didn't seem it was necessary to base64 the message content. I saw no 8 bit characters when I decoded it - just plain 7bit ascii. So it seems some systems are always doing it regarding of 7/8 bit. -- 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] 8bit downgrades
Ian Eiloart wrote: On 20 May 2011, at 05:24, Hector Santos wrote: In this case, if this is enforced with a MUST, for a system that is not 8BITMIME ready but is adding DKIM signing support, to remain compliant it is far more feasible to add a rule to a DKIM signing component: If mail is 8bit then SKIP signing. But why skip? Usually the message won't be downgraded. And even if they are, usually a broken signature will cause no harm. Thats the problem - define usually and also define no harm. -- 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] 8bit downgrades
On 23 May 2011, at 15:19, Hector Santos wrote: Ian Eiloart wrote: On 20 May 2011, at 05:24, Hector Santos wrote: In this case, if this is enforced with a MUST, for a system that is not 8BITMIME ready but is adding DKIM signing support, to remain compliant it is far more feasible to add a rule to a DKIM signing component: If mail is 8bit then SKIP signing. But why skip? Usually the message won't be downgraded. And even if they are, usually a broken signature will cause no harm. Thats the problem - define usually and also define no harm. Well, harm will only be done when someone incorrectly punishes a broken signature. They should not do that, so the damage is actually done by the recipient, not by the downgrading. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 23/May/11 06:35, Hector Santos wrote: Alessandro Vesely wrote: For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. I did the following Content-Transfer-Encoding failure analysis: Failure rates for message top level encoding type ++ | enctype total bodyfail pct | || | 8bit 31 25 80.6| It is not clear what part of these 8bit failures is due to messages that had been downgraded before signing, and then upgraded before verifying. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
Ian Eiloart wrote: Sorry, Pareto Efficiency (an economics concept) isn't something that I was familiar with. I was referring to an analysis Pareto charts (a quality engineering tool). Same guy, different concept. Actually, different guys (sciences, engineering disciplines), same concept. :) A Pareto chart looks at the different causes of a problem (signature breakage) and determines the relative frequency of each cause. This helps you to determine the benefit (but not the cost) of addressing each cause. And this provides an optimality. The purpose is to find an condition where it is Pareto Efficient (The best you can do without losing maximum benefit) because, like most things in life, there are always imperfections and most factors are interrelated in some fashion. So while its a tool to help identify problems, benefits, weakest, critical points, etc, there is a cause and effects and Pareto Optimality always comes into play. In a closed environment you have boundary conditions, and how much of one thing is done to correct, tweak, turn a knob in a process control plant, it can have an effect the other things and most important, a change which can move you away from being Pareto Efficient (optimal). My stats tell me that there's not much benefit in trying to persuade people to adopt relaxed versus simple. IMV, the specs should not be persuading other than explain what the purpose and reason for each one - let the reader decide. By and large, they're already doing that. For Exim users, that may be because relaxed is the software default. Agree, defaults is definitely a contributor especially for new deployments starting out. But, they do suggest the header mismatches are 10 times more common than body mismatches, so it may be worth focussing here. But in what way? We already have relaxed C14N for headers. I proposed the STRIP method in 2005 and that resolved the CRLF related issues I saw back then. Back in July 2005, I proposed the bh= among other diagnostic items for a DKIM-Signature-Debug debugging header of the header/body C14N thing: http://www.imc.org/ietf-mailsig/mail-archive/msg01817.html The bh= was added to the August 2006 base-01 draft. After the bh= hash is checked, its impossible to tell where the DKIM failure occurs afterwards (hash wise). The only extra debugging item you have it adding z= to see if any header value was changed. Personally, based on what I see, the signer should consider reducing the headers its signed and focus on the persistent core header never expected to change and even within the core headers, it definitely should avoid signing headers that are guarantee to change based on a known path it will take - like for an MKM, consider not hashing the 5322.Subject tag and use l= when the target path is known to be a list adding a footer. So with the Pareto Chart, we can include MLM and target/path as two of the items. -- 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] New canonicalizations
On 23 May 2011, at 16:00, Hector Santos wrote: Ian Eiloart wrote: Sorry, Pareto Efficiency (an economics concept) isn't something that I was familiar with. I was referring to an analysis Pareto charts (a quality engineering tool). Same guy, different concept. Actually, different guys (sciences, engineering disciplines), same concept. :) Not according to http://en.wikipedia.org/wiki/Pareto which names Vilfredo Pareto as the originator of the concept of Pareto efficency, and says that the Pareto chart was also named after him. I guess the one connection between the two concepts is that a Pareto chart is most useful if the causes identified are independent, and that fixing one cause of error won't aggravate another. -- Ian Eiloart Postmaster, University of Sussex +44 (0) 1273 87-3148 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
Ian Eiloart i...@sussex.ac.uk wrote: On 23 May 2011, at 15:19, Hector Santos wrote: Ian Eiloart wrote: On 20 May 2011, at 05:24, Hector Santos wrote: In this case, if this is enforced with a MUST, for a system that is not 8BITMIME ready but is adding DKIM signing support, to remain compliant it is far more feasible to add a rule to a DKIM signing component: If mail is 8bit then SKIP signing. But why skip? Usually the message won't be downgraded. And even if they are, usually a broken signature will cause no harm. Thats the problem - define usually and also define no harm. Well, harm will only be done when someone incorrectly punishes a broken signature. They should not do that, so the damage is actually done by the recipient, not by the downgrading. In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
Ian Eiloart wrote: On 23 May 2011, at 15:19, Hector Santos wrote: But why skip? Usually the message won't be downgraded. And even if they are, usually a broken signature will cause no harm. Thats the problem - define usually and also define no harm. Well, harm will only be done when someone incorrectly punishes a broken signature. They should not do that, Rhetorically, why not? Put another way, why should a receiver tolerate failure, or better, why should DKIM itself - the technology - tolerate failure? Sounds like DKIM has some inner soul turmoils - a devil on one shoulder and angel on the other. so the damage is actually done by the recipient, not by the downgrading. Well, thats a difference in two reasonable mindsets - a receiver who views faults as part of the strength of securing a technology and a receiver who tolerates faults - accepts everything including one that are direct and indirectly created and passes the buck to end-users. I like to believe there exist a commonality where false positive deterministic methods can be use to detect violations of an authentication and integrity technology. Rhetorically, its all for nothing, why bother looking at how to fix C14H hashing, talk about content formatting downgrades when failure is tolerated and per specification, deliberately ignored? -- 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] 8bit downgrades
In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent modification in transit, not malice. Do you have numbers to show that broken signatures indicate that messages are malicious, or spam, or otherwise worse than otherwise? For that matter, since we're not talking about ADSP, what do you mean by an absent signature? Do you track which domains sign what mail? How do you tell what signature you're expecting? From line domain? Sender? Message ID? Something in the Received lines? Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On Monday, May 23, 2011 12:35:02 PM John R. Levine wrote: In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent modification in transit, not malice. Which one is that? AFAIK treating a broken signature the same as no signature is what the RFC wants me to do. Do you have numbers to show that broken signatures indicate that messages are malicious, or spam, or otherwise worse than otherwise? None that I can share unfortunately. IME no signature is more suspicious than a broken one (as you suggest, I think most breakage is innocent), but putting broken and no signature into the same bucket is the most sensible and RFC compliant way to approach it. For that matter, since we're not talking about ADSP, what do you mean by an absent signature? Do you track which domains sign what mail? How do you tell what signature you're expecting? From line domain? Sender? Message ID? Something in the Received lines? The specific cases (which are non-ADSP) that I'm aware of use the body From as a key. Scott K ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] New canonicalizations
If one were to encode somehow an extension indication that this content was subjected to 8-to-7 downgrade as a hint that a verifier should do the reverse before verifying, the verifier would have to manage to undo the downgrade in precisely, i.e. byte-for-byte, the same manner that the downgrade was done for it to work. That's a pretty high requirement for interoperability (i.e., it's pretty error-prone), so it requires a specification and it would need to be consistent with the MIME RFCs. Seems to me that if someone were that desperate to get a signed message through a downgraded path, they should wrap the whole thing in a base64 encoded message/rfc822 mime part and send it that way. This all strikes me as mostly hypothetical, and unlikely to affect more than a tiny sliver of mail. The EAI group, which has way more experience with character set issues and downgrades than we do, tried all sorts of downgrade experiments and decided that none of them were workable. The current nearly final draft says that if you want to send an EAI message, you better find a path to the recipient that can deliver it as is. Perhaps we should take the hint. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Certifying the DKIM public key?
On 5/22/2011 10:43 AM, John R. Levine wrote: VBR queries are about an actor, not a message. Certs can be coupled to a particular message -- this was an interesting semantic distinction about Goodmail's certification scheme -- although I believe that typically they, too, are only scoped to the actor, not the specific content. Now I'm really confused. If the third party knows enough about each message to decide whether to provide the cert, why don't they just add their own DKIM signature? (Note that you are the one who introduced the construct of certifying a message.) In any event, there always needs to have an independent means of authenticating that a statement by a third party really is by them, whether it is through querying a portion of the DNS they own or by using their domain name to verify something in a message. So they probably /will/ add their own DKIM signature. But that's quite different from adding a signature with the domain of the organization producing the message, since this latter is the subject of the reputation/certification. (One could design this to remove the need for the latter signature, even while still including their domain name, I suppose.) The bottom line to this sort of exchange is that it seems pretty clear that as a community we are not clear about concepts or details for this topic. That one or another person thinks one or another issue has an obvious answer is turning out to be a poor indicator of actual community understanding or agreement. As an impressive example of even deeper misunderstanding: On 5/22/2011 10:49 AM, Michael Thomas wrote: On 05/22/2011 10:27 AM, John R. Levine wrote: It occurs to me that since mail certification is likely to make assertions about behavior as well as identity, the SSL model in which certs last for a year won't work, since behavior can change rapidly. Either the certifier has to issue a stream of short-term certs to everyone it certifies, or the verifiers have to check CRLs, which is tedious. By the time you do all that, a DNS check, even one with DNSSEC, looks pretty attractive. But this is exactly what DKIM is. You prove yourself fsvo prove to the registrar who certifies you by virtue of placing your NS records in the root servers instead of issuing a cert. Nothing different in *essence* to x.509 certs. DKIM has almost literally nothing to do with proofs made to a DNS registrar. For example, it says nothing about the relationship between a domain name and a brand or company name. DKIM merely says that who ever owns use of a domain name is asserting some responsibility for the signed message. In extremely abstract terms, a DKIM signature relates to a reasonably constant construct that one might call an identity but it does not label the identity, except with the domain name. More importantly, there are none of the claims, assertions or endorsements that go along with Certs, except for the mild one noted above. One would have expected a former author of the spec who so-often proclaims their expertise to understand the semantics of DKIM better. On the other hand, it does nicely show that implementing code doesn't mean understanding what it is for... 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] Certifying the DKIM public key?
On 05/23/2011 11:17 AM, Dave CROCKER wrote: As an impressive example of even deeper misunderstanding: More of CROCKER's famed civility. On 5/22/2011 10:49 AM, Michael Thomas wrote: But this is exactly what DKIM is. You prove yourself fsvo prove to the registrar who certifies you by virtue of placing your NS records in the root servers instead of issuing a cert. Nothing different in *essence* to x.509 certs. DKIM has almost literally nothing to do with proofs made to a DNS registrar. For example, it says nothing about the relationship between a domain name and a brand or company name. Where exactly did I say anything about a brand or a company? Oh, I didn't. DKIM merely says that who ever owns use of a domain name is asserting some responsibility for the signed message. Yes, and the way that they got to assert that was by convincing a registrar to allow them to create and maintain NS records in the root servers. In extremely abstract terms, a DKIM signature relates to a reasonably constant construct that one might call an identity but it does not label the identity, except with the domain name. A domain name is an identity. RFC4871 calls it the signing identity. More importantly, there are none of the claims, assertions or endorsements that go along with Certs, except for the mild one noted above. Assertion of identity is mild? It's the *key* assertion. One would have expected a former author of the spec who so-often proclaims their expertise to understand the semantics of DKIM better. On the other hand, it does nicely show that implementing code doesn't mean understanding what it is for... I'm not a former author. But thanks for the smear anyway. Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
Alessandro Vesely wrote: On 23/May/11 06:35, Hector Santos wrote: Alessandro Vesely wrote: For example, MTAs that autoconvert from quoted-printable to 8bit, a rather common circumstance. I did the following Content-Transfer-Encoding failure analysis: Failure rates for message top level encoding type ++ | enctype total bodyfail pct | || | 8bit 31 25 80.6| It is not clear what part of these 8bit failures is due to messages that had been downgraded before signing, and then upgraded before verifying. None. Of the 31, 20 were from Keith Moore signed messages into the IETF-SMTP list with a 3rd party signature and Hoffman's list server (non-dkim aware) doing this: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hoffman.proper.com id p4BLC7Hl032165 These 20 all failed and the hop count was 6. It was the only list message, Of the remaining 11, all spam, all direct (hops=1), 5 failed - 2 domains - 3 pure American Spam and 2 Spanish Spam. Moore sent me a direct email recently, and from what I can see, its the same 3rd party signer with: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable -- 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] New canonicalizations
On 23 May 2011, John R. Levine wrote: Seems to me that if someone were that desperate to get a signed message through a downgraded path, they should wrap the whole thing in a base64 encoded message/rfc822 mime part and send it that way. That's explicitly forbidden by RFC 2046. Some idiot lazy MUA writer sought a guarantee that his MUA would be able to look inside forwarded-as-attachment mail without having to handle multiple layers of encoding. He got it. Thus, no multipart or message/rfc822 object can be base64 or QP encoded. Because of that arrogant decision, a downconversion for a message containing a message/rfc822 element under 8bit CTE (which *is* legal), simply isn't defined. Michael Deutschmann mich...@talamasca.ocis.net ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
There is an interesting post today on http://chilli.nosignal.org/mailman/listinfo/mailop about exim and 8bit It seems they will stop to downgrade. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
On 5/23/11 6:35 PM, John R. Levine wrote: In the real world signature reliability matters. If a domain signs mail as a rule then an absent or broken signature will be treated as suspicious. I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, and in my experience, most broken signatures are due to innocent modification in transit, not malice. Do you have numbers to show that broken signatures indicate that messages are malicious, or spam, or otherwise worse than otherwise? SpamAssassin assigns a score of something like 0.1 for a message carrying a DKIM signature and compensates that with -0.1 if the signature can be verified to be correct. Effectively, this means SA is penalizing broken signatures... /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
At 11:03 23-05-2011, Dave CROCKER wrote: Then you are using criteria that go beyond the requirements of a BCP. From RFC 2026: 5. BEST CURRENT PRACTICE (BCP) RFCs The BCP subseries of the RFC series is designed to be a way to standardize practices and the results of community deliberations. ... The BCP subseries creates a smoothly structured way for these management entities to insert proposals into the consensus-building machinery of the IETF while gauging the community's view of that issue. Nothing in the definition of BCPs require that it be limited to covering existing practice. This creates debates along the lines of the RFC says so or the IETF says that this should be the practice. Perhaps the wording is a bit more coarse than one would like, but at base, telling the community what to do is what standards-track and BCP documents do, whether based on existing practice or not. A RFC is a way of telling the community what you did and how you did it. If people believes it is a good idea, they will pick it up. I'll diverge from the topic. Let's say that you are writing a proposal and there is a controversial issue. You are technically correct in your arguments but there are several people who disagrees with you on the issue. Your options are: (i) Don't make a change (assuming the IESG is fine with that) (ii) Make a change to gain goodwill (they will implement your proposal) I leave it to the IETF to determine which option to pick. Not really. The latter paragraph merely notes that there are receivers that do not understand what a DKIM signature means. I'll stick to my previous comments on this to avoid further distractions to the draft. You country has one of those, too? No, but I came across abuse reports where the people mentions that they will contact one of those about the matter. :-) Again, we seem to have an attempt to impose a more stringent requirement on qualifying for BCP status than exists in IETF formal documentation. At 11:43 23-05-2011, John Levine wrote: But since this argument seems to be all about proving that we've followed the official process rather than about publishing something accurate and useful rather than speculative and misleading, who cares? Now that I understand the rules, I plan to publish all of my experiments as BCPs. One little gem from an I-D which will be published as a BCP is that the information is intended to reflect consensus on the ground. A RFC is not worth a pinch of salt if it override that. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 8bit downgrades
Hi Rolf, At 15:09 23-05-2011, Rolf E. Sonneveld wrote: SpamAssassin assigns a score of something like 0.1 for a message carrying a DKIM signature and compensates that with -0.1 if the signature can be verified to be correct. Effectively, this means SA is penalizing broken signatures... Not really. There is a score so that the rules are evaluated. It doesn't weigh much in practice. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP
Dave CROCKER wrote: ? In Section 5.8: DKIM-aware authoring MLMs MUST sign the mail they send according to the regular signing guidelines given in [DKIM]. One concern is that having an MLM apply its signature to unsigned mail might cause some verifiers or receivers to interpret the signature as conferring more authority or authenticity to the message content than is defined by [DKIM]. This is an issue beyond MLMs and primarily entails receive-side processing outside of the scope of [DKIM]. It is nevertheless worth noting here. Removing the MUST and saying: DKIM-aware authoring MLMs signs the messages they send according to the regular signing guidelines given in [DKIM] gives more weight to the last two paragraphs, especially with the note about the concern. Not really. The latter paragraph merely notes that there are receivers that do not understand what a DKIM signature means. Something is amiss if after 6 years of development, after countless repeated explanations and messages over the years, it still seems very a difficult feat to describe in one or two sentences to the layman what DKIM is suppose to do for them, today or in the some distance future. The fact is DKIM has many conflictive semantics. While the above says its out of scope, it says the opposite in RFC 46751bis 6.3: Once the signature has been verified, that information MUST be conveyed to the Identity Assessor (such as an explicit allow/ whitelist and reputation system) and/or to the end user. If the SDID is not the same as the address in the From: header field, the mail system SHOULD take pains to ensure that the actual SDID is clear to the reader. See the SHOULD? See the technical association highlighted between the signer domain (SDID) and the the originating, copyright holder/author of the Message? Now, look at the conflict in the Abstract and repeated again in Section 1.2 defining the Signing Identity: DKIM separates the question of the identity of the signer of the message from the purported author of the message. What question is that? RFC4871 never quite clearly defined thee question. Lets think about what that question may be. Answer this: Do Electronic Mail Author Domains have any security rights and controls over who DKIM signs their mail? Be nice for someone to answer that question. Then of course, we have augmented RFC productions, such as RFC5585 that describes the DKIM Service Architecture and the illustration has that Author Domain Checking Signing Practices process component displayed in the diagram: |- RFC5322 Message V ++++ | Private|| ORIGINATING OR RELAYING ADMD | | Key+...| Sign Message with SDID| | Store |+---++ ++| (paired) [Internet] ++| +---+ | Public |++| Remote| | Key|| RELAYING OR DELIVERING ADMD || Sender| | Store || Message Signed? || Practices | ++---++-++-++-+-+ . |yes |no . . V|. .+-+|. +...| Verify ++ |. | Signature || |. +--+--+| |. pass| fail| |. V | |. +-+| |. | || |. +...| Assessments || |. .| |V V. .+-+--++ +---+ . . | | / Check \+ . | +/ Signing \ . | / Practices \..+ . | +---+---+ . . | | . . | V . +++ |+---+ +--+-+ |Reputation/ | || Message | | Local Info | |Accreditation| +---| Filtering | | on Sender | |Info | | Engine| | Practices | +-+ +---+ ++ Figure 1: DKIM Service Architecture Then you have the RFC5863 Development guide with a few dedicated sections, but not the only sections: 7.3. Author Domain Signing
Re: [ietf-dkim] 8bit downgrades
Murray S. Kucherawy wrote: -Original Message- What this tells me is: Ignoring ADSP, if a domain sometimes signs its mail, then mail from it (signed or not) is usually not spam. From this I suspect we could conclude that a missing signature doesn't tell us much of anything. And it would be an incorrect conclusion. This shows a lack of understanding of policy concepts. Look, I can clearly say right now, that 100%, not 99.99% of all DKIM signed mail in my PCN have untrusted SIGNERS even if I known who they are - they are 100% not vouched. I will venture that the majority DKIM receivers see a 100% or close to it. Is that evidence to conclude that the TRUST idea is bad? No. Now, if I had a local table of TRUSTED signer domains, then I can make an assertion that an VALID signature from that signer is ok, but if I see it broken, its going to a classification that is lower than OK. In the same vain if an Author Domain has a policy says THIS, but you see THAT, thats a clear policy violations. Either way, Author or Signer - there is always a policy concept involved - when you have neither, then we have want we have now which is pretty much nothing. -- 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
