Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID "Originating Domain Identity"
> For what it's worth, our stats show that it is in use on 3.58% of > signatures received since August. Do you have enough data to know in how many of those 3.58% the body wasn't the same length as the l= value ? Looking at my much smaller archive, it appears that in most cases the l= matches the body length so ignoring l= would make no practical difference. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID "Originating Domain Identity"
> -Original Message- > From: John Levine [mailto:jo...@iecc.com] > Sent: Friday, May 06, 2011 5:37 AM > To: ietf-dkim@mipassoc.org > Cc: Murray S. Kucherawy > Subject: Re: [ietf-dkim] 23 again (sorry John) was Output summary - > proposing ODID "Originating Domain Identity" > > > For what it's worth, our stats show that it is in use on 3.58% of > > signatures received since August. > > Do you have enough data to know in how many of those 3.58% the body > wasn't the same length as the l= value ? > > Looking at my much smaller archive, it appears that in most cases the > l= matches the body length so ignoring l= would make no practical > difference. Yes, that's here: http://www.opendkim.org/stats/report.html#l_tag You can see the count that have "l=" smaller than the final message size as well as the "l=0" ones, and how many of those passed or failed. That's out of 155972 signatures that used "l=", and 4.36M total signatures observed, in just over eight months of data. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID "Originating Domain Identity"
On 05/May/11 22:54, Barry Leiba wrote: If this is the sort of advice we are going to give then we should just deprecate "l=". >>> >>> +1: it was an error in the PS and the DS fixes it. >>> >>> Alternatively we can allow it, warn, and expect implementers to code >>> heuristics that can discern attacks from regular footers. >> >> Speaking as an implementer, I ignore l=, because the hassle of working >> around it and trying to guess how hostile any added content might be is >> vastly greater than any utility it has. > > We certainly could deprecate it, and add something that says that > verifiers MAY consider a signature for which l= is less than the full > message length to fail verification. Such a change should have been > proposed earlier in the process, but I won't consider it out of scope > if we have consensus to do that now. One place to put a normative "MAY" is in the last paragraph of section 6.1.3 "Compute the Verification". E.g., replacing it with A body length specified in the "l=" tag of the signature limits the number of bytes of the body passed to the verification algorithm. Any added content, that is text beyond that limit, is not validated by DKIM, whether it was present at the time of signing or not. Verifiers MAY apply whatever heuristics in order to determine the legitimacy of existing added content; in particular, verifiers MAY consider any added content hostile and hence return PERMFAIL (unsigned content) for signatures having l= less than the full message length. If something like this is stated, the INFORMATIVE IMPLEMENTATION WARNING of section 3.5 should be modified so as to avoid redundancy. E.g. by replacing To avoid this attack, signers should be extremely wary of using this tag, and verifiers might wish to ignore the tag with, say, To avoid this attack, signers should be extremely wary of using this tag, unless they know what heuristics verifiers will apply. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Protocol layering / Software vs. Protocol
On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba wrote: > Doug says... >> This can *only* be achieved by some mandatory test within the Verifier. > > Not at all; that's exactly Dave's point in discussing the difference > between the protocol and the software system that wraps around it. > The Verifier is a component that verifies the signature, and that's > all we're defining normatively here. Other parts of the system will > evaluate things whether the verified signature can be relied upon, and > what it can be relied upon for; whether the domain that signed it is > trustworthy; whether a failed signature can nonetheless provide useful > information; and so on. Not so. As you should know from off-list discussions, that sentence is actually mine, though used in a marginally different context than Doug used it. IF there were to be some "mandatory test within the Verifier", then that test would be, ipso facto, a part of the protocol and not part of the "software system that wraps around it". So your argument was circular :-( . -- 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] l= statistics was 23 again (sorry John) was Output
> http://www.opendkim.org/stats/report.html#l_tag > > You can see the count that have "l=" smaller than the final message size as > well as the "l=0" ones, and how many of those passed or failed. > > That's out of 155972 signatures that used "l=", and 4.36M total signatures > observed, in just over eight months of data. Hmmn. If my arithmetic is right, about 95% of l= signatures didn't cover the whole body, and only a few of those were l=0. Your users must subscribe to different mailing lists than I do. 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] l= statistics was 23 again (sorry John) was Output
On 5/6/11 4:35 PM, John R. Levine wrote: >> http://www.opendkim.org/stats/report.html#l_tag >> >> You can see the count that have "l=" smaller than the final message size as >> well as the "l=0" ones, and how many of those passed or failed. >> >> That's out of 155972 signatures that used "l=", and 4.36M total signatures >> observed, in just over eight months of data. > Hmmn. If my arithmetic is right, about 95% of l= signatures didn't cover > the whole body, and only a few of those were l=0. Your users must > subscribe to different mailing lists than I do. John, the opendkim project gathers information from various sources, they're not necessarily the users of Murray and they're not necessarily subscribed to mailing lists. The statistics also doesn't tell which inbound mail is from legitimate sources and which inbound mail is from spammers/bad guys. Maybe the 95% you mention, are the spammers who try to abuse l= in DKIM... /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] > Sent: Friday, May 06, 2011 8:12 AM > To: John R. Levine > Cc: Murray S. Kucherawy; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > John, the opendkim project gathers information from various sources, > they're not necessarily the users of Murray and they're not necessarily > subscribed to mailing lists. The statistics also doesn't tell which > inbound mail is from legitimate sources and which inbound mail is from > spammers/bad guys. Maybe the 95% you mention, are the spammers who try > to abuse l= in DKIM... Correlation against Spamassassin results is possible, though the data set is more limited because only a few reporting hosts include that extended data. I'm not sure what this tells you but here it is: ++--+--+ | l= present | pass | spam | ++--+--+ | 4902 |0 |0 | |307 |0 |1 | | 49265 |1 |0 | |775 |1 |1 | ++--+--+ +--+--+--+ | l=0 | pass | spam | +--+--+--+ | 3357 |0 |0 | | 305 |0 |1 | | 3386 |1 |0 | | 14 |1 |1 | +--+--+--+ +--+--+--+ | l= < msgsize | pass | spam | +--+--+--+ | 4819 |0 |0 | | 307 |0 |1 | |43539 |1 |0 | | 768 |1 |1 | +--+--+--+ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, May 06, 2011 7:35 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > > http://www.opendkim.org/stats/report.html#l_tag > > > > You can see the count that have "l=" smaller than the final message > > size as well as the "l=0" ones, and how many of those passed or failed. > > > > That's out of 155972 signatures that used "l=", and 4.36M total > > signatures observed, in just over eight months of data. > > Hmmn. If my arithmetic is right, about 95% of l= signatures didn't cover > the whole body, and only a few of those were l=0. Your users must > subscribe to different mailing lists than I do. Might not be list traffic. But I have data for that too. Count of signatures with "l=" that did or didn't appear to pass through an MLM: +--+--+ | count(*) | mailing_list | +--+--+ |77246 |0 | |78853 |1 | +--+--+ ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
John R. Levine wrote: >> http://www.opendkim.org/stats/report.html#l_tag >> >> You can see the count that have "l=" smaller than the final message size as >> well as the "l=0" ones, and how many of those passed or failed. >> >> That's out of 155972 signatures that used "l=", and 4.36M total signatures >> observed, in just over eight months of data. > > Hmmn. If my arithmetic is right, about 95% of l= signatures didn't cover > the whole body, and only a few of those were l=0. Your users must > subscribe to different mailing lists than I do. of course, we don't all live in the same levine list world. What I found in a quick grep scan of ~7000 list messages: 137 used l= with some value 3 used l=0 from the same source More details: - Sorted down to 37 domains, 36 unknown, 1 known domain, - Except for 1 known, all mail from the 36 was spam, - 20 of them had the same patterns but different domains, and - the 20 used two signatures, sha1 and sha256 The collection were saved prior to verification so I don't know off hand if they failed or the actual body counts. In my network of mail, I will say, l= is used by spammers blasting list mail to their collected emails addresses to spam. -- 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] Output summary - Keep your Eye on the Prize!
Murray S. Kucherawy wrote: >> -Original Message- >> Therefore with no subjective consideration, no assertions, no >> philosophies, the protocol defines a process model of: >> >> trust = TrustIdentityAssessor(SDID [,AUID]) >> >> There is NO opinion about this! That is your DKIM Trust Protocol Model >> with a Mandatory SDID input and an optional AUID input. > > Actually, using your notation, it's: > > trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]]) > > How far do we really need to go here? As far are the protocol technical specification says it is. However, isn't these additional parameters not part of a Trust Assessor functionality and are part of the validation functionality? In principle, the RFC4871 process model prototyping using a dyadic FP (Functional Programming) methodology would be overall: MAIL.PAYLOAD= MAIL_FEED() VERIFY.OUTPUT = DKIM_VERIFY(MAIL.PAYLOAD) ACCESSOR.OUTPUT = DKIM_ACCESSORS(VERIFY.OUTPUT, MAIL.PAYLOAD) In this summary prototype, MAIL.PAYLOAD provides all the inputs (RFC5322 message) for both verification and for any inputs required for any assessors in the process. The only new data would be included within the VERIFY.OUTPUT and ASSESSOR.OUTPUT namespaces. With 3.9, VERIFY.OUTPUT is defined to be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID Without 3.9, the technical reading extraction would be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID VERIFY.OUTPUT.AUID and IMO, per RFCs 4686, 5016, 5617, 5585, 5863 it would be: VERIFY.OUTPUT.RESULT VERIFY.OUTPUT.SDID VERIFY.OUTPUT.AUID VERIFY.OUTPUT.ODID To exclude AUID and/or ODID, it would be a subjective conclusion for a specific implementation mandate. >> To be consistent you have three protocol design tech writing choices: >> >>1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. >>2) Add AUID to 3.9 as an optional output >>3) Remove section 3.9 > > or the solution I'm beginning to like: > > 4) Alter 3.11 to match 3.9. or take out 3.11 and like it was done for RFC5322.From, you can modify the two references to the unfortunate technically incorrect sentence in the abstract and section 1.2: DKIM separates the question of the identity of the signer of the message from the purported author of the message. What "question" are we separating? The association? It would be technically incorrect given the binding requirement. In lieu of ADSP, it may be a policy-based association separation but still an DKIM-based association of authenticity. As long as "Purported Author" is a fundamental requirement to be bound to the signature, it will always be an inherent association between the signer and author that can not be separated. Maybe it can be change to a more functionally correct description: DKIM provides a mechanism which allows for the separation of the authorized association|relationship of the identity of the message signer from any other agent or user identity, including the originating author domain. Anyway -- 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] Output summary - Keep your Eye on the Prize!
On 5/5/11 9:40 PM, Hector Santos wrote: > Dave CROCKER wrote: > I don't think this is correct. The signer creates and signs the i= value, so it's not "garbage", >> >>> By "garbage", I mean "not guaranteed to have any useful meaning". >> >>> So, I believe, it's essentially meaningless as far as the protocol can >>> stipulate. Assertions of its semantics thus fall outside of the base DKIM >>> spec. >> It's worth noting that Murray said 'could be'. >> >> But Murray's final paragraph has the essential points: within the scope of >> the >> DKIM Signing specification, the receive-side has no way to determine what the >> semantics of i= are, as we discussed at great length when formulating the >> Update >> RFC. >> >> But, then, folks on the list already know that. > "We have here is a failure to communicate." - Cool Hand Luke > > Dave, > > This approach you have is an implementation conclusion. It is not > part of the protocol. The protocol clearly says in 3.11: > > Upon successfully verifying the signature, a receive-side DKIM > verifier MUST communicate the Signing Domain Identifier (d=) to a > consuming Identity Assessor module and MAY communicate the Agent or > User Identifier (i=) if present. > > Therefore with no subjective consideration, no assertions, no > philosophies, the protocol defines a process model of: > > trust = TrustIdentityAssessor(SDID [,AUID]) > > There is NO opinion about this! That is your DKIM Trust Protocol Model > with a Mandatory SDID input and an optional AUID input. > > In order for this to work, your 3.9 Output Requirement MUST expose > those two parameters at the very least. There is no assertions or > opinions - thats the protocol you defined. > > Now, when you begin to exclude it, then you mixing up implementation > desires with subjective conclusion that really is not part of the > protocol defined. There is some subjective information notes about > the value, but that has nothing to do with the protocol you defined. > > To be consistent you have three protocol design tech writing choices: > > 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed. > > 2) Add AUID to 3.9 as an optional output > > 3) Remove section 3.9 > > This is what happens when you add something in the last minute without > any consensus. It was just added - no consensus. I must agree with Hector on this point. It seems the motivation to "simplify" DKIM has wrongly included removal of output information intended to be bound with the signature. It would be like SMTP later deciding not to include trace information intended to be bound with the message. While the "i=" may contain the email address of the author or the postmaster of the domain or simply an opaque tag, the meaning is NOT undefined. Its meaning IS defined by the signing domain. The whole point of DKIM was to establish a context for such information, especially information intended to be closely bound with the signature. Deprecating that aspect of DKIM overlooks many security aspects, and the valid and intended use of this information. What this parameter had been defined should ensure against any interoperability issues, but perhaps deserves a warning that it NOT be used by third parties who are unaware of the signing domains definition of this field. It would still be extremely useful within enterprise applications, for example. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
On 05/06/2011 08:12 AM, Rolf E. Sonneveld wrote: > John, the opendkim project gathers information from various sources, > they're not necessarily the users of Murray and they're not necessarily > subscribed to mailing lists. The statistics also doesn't tell which > inbound mail is from legitimate sources and which inbound mail is from > spammers/bad guys. Maybe the 95% you mention, are the spammers who try > to abuse l= in DKIM... > Good luck with spammers trying abuse that. A naive filter wouldn't know at all about l= but are well acquainted with spammers inserting good looking text with spammy text. A dkim aware filter would be even less impressed as the unsigned content would stick out like a sore thumb. For all of the hysterical warnings in the spec, it would be nice to hear about even ONE successful abuse. It's been, what, 5 years now? Mike ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] Ticket #24
The intended content of this ticket by Charles Lindsey, Rolf Sonneveld and my self is as follows: ,--- We were asked by Barry to provide an agreed text to resolve the "multiple header" problem, for consideration by the WG. The attack arises when some header (typically From:) which is supposed to appear once in fact appears twice. DKIM is REQUIRED to sign the bottom one, whereas most email agents will only display or use the top one. There are three forms of the attack: 1. Some man-in-the-middle adds a header to some already signed message. 2. An earlier validly signed message is replayed with an added header. 3. The message is signed by the Bad Guy himself (d="my-throwayay-domain.com") with two headers, of which he hopes the recipient will see only the top (unsigned) one. The proposed technique of signing with 'h="from:from"' works fine in the first two cases (where the signer can be presumed honest) but fails totally when this technique is not used by a "to big to block" domain and in the third where he most certainly is not honest. We are concerned that all who see a validly signed message which appears to be From: somewh...@ebay.com will be able to *rely* on what they see, whether they understand DKIM, or whether they have just been told that their ISP does some magical trick to "detect people masquerading as Ebay". DKIM can not limit its validation to process to just signature confirmations. This approach would then expect existing email agents to adopt DKIM's unusual header selection methods retro-actively. To be compatible with existing email infrastructure and transparent to the fullest extent possible, one can not expect new supporting infrastructure or modified clients; This can *only* be achieved by some mandatory test within the Verifier. We propose two wordings; one which tests for all once-only headers, and a less desirable minimalistic version just testing for a duplicate From: (which would be the cause of the worst scams, though lesser attacks involving other headers have been mentioned on the WG. 1. Add: --- 6.1.n. Validate Multiple Header Field Occurrences Through inadvertence or malice, a message may be received having multiple occurrences of single only header fields per [RFC5322]. To provide results upon which subsequent agents can rely, verifiers MUST detect an invalid number of single only header fields present within the Signature header field's "h=" list and return PERMFAIL (illegal multiple header fields). See Sections 8.14 and 8.15 for further discussion of such attacks. 2, Add to 6.1: --- To provide results upon which subsequent agents can rely, verifiers MUST detect an invalid number of From header fields and return PERMFAIL (illegal multiple headers. [RFC5322] requires there be exactly one From header field. See Sections 8.14 and 8.15 for further discussion of header field considerations. --- Editor's Note: Wording within Sections 8.14 or 8.15 may need to change slightly to be in alignment with these changes. NOTE. We claim that these wordings make no layering violations. They affect only operations required to be performed as part of the DKIM protocol. The result reported by the verifier will still be just PASS/PERMFAIL/TEMPFAIL, and whether or not the (malformed) message gets forwarded to the recipient (possibly annotated with warnings) is a matter for the Assessor, not for DKIM. '--- -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Protocol layering / Software vs. Protocol
On 5/6/11 6:28 AM, Charles Lindsey wrote: > On Thu, 05 May 2011 21:24:00 +0100, Barry Leiba > wrote: >> Doug says... >>> This can *only* be achieved by some mandatory test within the Verifier. >> Not at all; that's exactly Dave's point in discussing the difference >> between the protocol and the software system that wraps around it. >> The Verifier is a component that verifies the signature, and that's >> all we're defining normatively here. Other parts of the system will >> evaluate things whether the verified signature can be relied upon, and >> what it can be relied upon for; whether the domain that signed it is >> trustworthy; whether a failed signature can nonetheless provide useful >> information; and so on. > Not so. As you should know from off-list discussions, that sentence is > actually mine, though used in a marginally different context than Doug > used it. > > IF there were to be some "mandatory test within the Verifier", then that > test would be, ipso facto, a part of the protocol and not part of the > "software system that wraps around it". So your argument was circular :-( . This sentence was indeed written by Charles. He is far more eloquent, and I wanted to respond but was rushed by other pressing security matters. While we have collaborated in creating something that should better clarify DKIM's role, it is my opinion verification requirements are better stated as MUST. Unreliable Assurances are Worse than NONE. From the aspect of proper protocol design and layering aspects, proper design must not expect consumers of the protocol to second guess the validity of the inputs used, especially when these inputs become less clear in the process. SMTP can not be expected to ensure header field ordering, especially those defined by DKIM. The modern version of the message format also clearly stipulates which header fields are required not to repeat. The premise used by DKIM in requiring the From header field to be signed, incorrectly assumed that by requiring this header field to be included in the signature's validation, the particular header field would be obvious to subsequent consumers of its output. This was clearly a mistake made by DKIM that MUST BE corrected. As email transitions into the use of UTF-8, DKIM's role in better securing messages becomes even more significant. As such, it is important to embrace the incumbent obligations. DKIM must not blame SMTP or DNS for its failings. -Doug ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> Might not be list traffic. But I have data for that too. Count of > signatures with "l=" that did or didn't appear to pass through an MLM: > > +--+--+ > | count(*) | mailing_list | > +--+--+ > |77246 |0 | > |78853 |1 | > +--+--+ That's just strange. Most of the l= signatures don't cover the whole body, and half of those didn't go through a mailing list? 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] Ticket #24
I have just updated the tracker ticket for this: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 To be concise, here are the proposed changes. The group's preferred change, #1, is this: > 1. Add: > --- > 6.1.n. Validate Multiple Header Field Occurrences > > Through inadvertence or malice, a message may be received having > multiple occurrences of single only header fields per [RFC5322]. To > provide results upon which subsequent agents can rely, verifiers MUST > detect an invalid number of single only header fields present within the > Signature header field's "h=" list and return PERMFAIL (illegal multiple > header fields). > > See Sections 8.14 and 8.15 for further discussion of such attacks. That asks for a lot, so the group has a second alternative, #2, which only asks for the "from": > 2, Add to 6.1: > --- > To provide results upon which subsequent agents can rely, verifiers MUST > detect an invalid number of From header fields and return PERMFAIL > (illegal multiple headers. [RFC5322] requires there be exactly one > From header field. > > See Sections 8.14 and 8.15 for further discussion of header field > considerations. While I address the other two open tickets, do the IESG writeup, and otherwise get ready to send 4871bis to the IESG, everyone please take the time to read Doug's note and weigh in on these two alternatives. Let us know, in this thread, whether you support one or the other of them, or whether you prefer the text as it currently is in the -09 version of 4871bis. If you have anything to say in argument for or against, please keep it VERY BRIEF. This is a call for new consensus, and the arguments have been made at length already. We need to see rough consensus *for* one of these changes in order to make them. I'll let this float for a few days -- I expect to be ready with the writeup by the middle of next week. Barry, as chair ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #24
I appreciate the work that Doug and Charles put into their proposal, but for reasons already discussed, I think we should leave section 6.1 as is in -09. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Ticket #24
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John Levine > Sent: Friday, May 06, 2011 11:15 AM > To: ietf-dkim@mipassoc.org > Cc: barryle...@computer.org > Subject: Re: [ietf-dkim] Ticket #24 > > I appreciate the work that Doug and Charles put into their proposal, > but for reasons already discussed, I think we should leave section > 6.1 as is in -09. +1. Sections 3.8, 8.14 and 8.15 already say enough about this issue. -MSK ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, May 06, 2011 10:50 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > > Might not be list traffic. But I have data for that too. Count of > > signatures with "l=" that did or didn't appear to pass through an MLM: > > > > +--+--+ > > | count(*) | mailing_list | > > +--+--+ > > |77246 |0 | > > |78853 |1 | > > +--+--+ > > That's just strange. Most of the l= signatures don't cover the whole > body, and half of those didn't go through a mailing list? I suspect it's use of "l=" by a signer without regard to whether or not the mail is heading to an MLM. For example, OpenDKIM's antecedent had that as an option; only the evolution to OpenDKIM allowed you to be more specific. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output requirements
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Thursday, May 05, 2011 1:08 PM > To: Charles Lindsey > Cc: DKIM > Subject: Re: [ietf-dkim] Output requirements > > >> + Verifiers SHOULD ignore those signatures that produce a PERMFAIL > >> + result (see Section 7.1), acting as though they were not present > in > >> + the message. ... > > > > s/Verifiers SHOULD ignore/Identity assessors SHOULD ignore/ > > > > (and probably in other places too). Verifiers are explicitly instructed > > to return PERMFAIL/TEMPFAIL), and "returning" something is evidently > > inconsistent with "ignoring" it. > > +1 Since this is already somewhat mushy, might I suggest: Verifiers MAY decline to report, and identity assessors SHOULD ignore, ... ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
This was a delayed notice. There's not actually a new version today.
> -Original Message-
> From: i-d-announce-boun...@ietf.org [mailto:i-d-announce-
> boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
> Sent: Friday, May 06, 2011 11:30 AM
> To: i-d-annou...@ietf.org
> Cc: ietf-dkim@mipassoc.org
> Subject: I-D ACTION:draft-ietf-dkim-mailinglists-08.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 : DKIM And Mailing Lists
> Author(s) : M. Kucherawy
> Filename : draft-ietf-dkim-mailinglists-08.txt
> Pages : 31
> Date : 2011-04-27
>
>DomainKeys Identified Mail (DKIM) allows an administrative mail
>domain (ADMD) to assume some responsibility for a message. Based on
>deployment experience with DKIM, this Best Current Practices document
>provides guidance for the use of DKIM with scenarios that include
>Mailing List Managers (MLMs). {DKIM 12}
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-08.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.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
>>> +--+--+ >>> | count(*) | mailing_list | >>> +--+--+ >>> |77246 |0 | >>> |78853 |1 | >>> +--+--+ >> >> That's just strange. Most of the l= signatures don't cover the whole >> body, and half of those didn't go through a mailing list? > I suspect it's use of "l=" by a signer without regard to whether or not > the mail is heading to an MLM. For example, OpenDKIM's antecedent had > that as an option; only the evolution to OpenDKIM allowed you to be more > specific. Except that doesn't explain why l= doesn't cover the entire body. Signing or verifying bug? Clever spammer replaying signed mail and getting away with it? Forwarders of some sort that add a footer but otherwise don't look like mailing lists? 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] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Thursday, May 05, 2011 3:24 PM > To: dcroc...@bbiw.net > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] issue: Section 2.6/ 3.5 AUID/i= should have pubkey > t=s info > > > Repeating or rephrasing specification text invites divergent > > interpretations. > > Indeed, and I agree that not repeating is best. On the other hand, > we're already repeating the part about "or a subdomain of", which is > why I support adding a notation about "except when t=s". > > > Note the constraint on the value of "i=" that is imposed by the > > "t=s" tag of > > the stored key record. (See Section 3.6.1). > > That works for me. Seems minor, editorial and useful. Added for the next version. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Friday, May 06, 2011 11:43 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > >>> +--+--+ > >>> | count(*) | mailing_list | > >>> +--+--+ > >>> |77246 |0 | > >>> |78853 |1 | > >>> +--+--+ > >> > >> That's just strange. Most of the l= signatures don't cover the whole > >> body, and half of those didn't go through a mailing list? > > > I suspect it's use of "l=" by a signer without regard to whether or not > > the mail is heading to an MLM. For example, OpenDKIM's antecedent had > > that as an option; only the evolution to OpenDKIM allowed you to be more > > specific. > > Except that doesn't explain why l= doesn't cover the entire body. > > Signing or verifying bug? Clever spammer replaying signed mail and > getting away with it? Forwarders of some sort that add a footer but > otherwise don't look like mailing lists? My guess is the third one. The specification for what we decide is a mailing list submission isn't bulletproof, but is listed as: - has a "Precedence: list" field - has a "List-Id: field - has a "List-Post:" field - has a "List-Unsubscribe:" field - has a "Mailing-List:" field If there are other metrics that are easily detected, I could add monitoring for them and then cut off future reports at today's date, or something like that. There's also the whole thing about "l=" is the post-canonicalization body count, not the actual full message byte count. I'll double-check on that logic. This won't change the "l=" use information though, just the pass/fail reporting accuracy. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
We've had a bit of discussion in this thread (and elsewhere) about this, but I need to get a clear view of consensus. Doug agrees with Hector's note, below, and Dave and Murray do not. I'd like to hear from others within the next few days, about whether you think we should make the change Hector requests or not. I need to get a sense of whether there's significant support for it. Again, please keep arguments to a minimum, so it's clearer to me what the consensus is -- we've had the arguments going for a while now. Barry, as chair On Wed, May 4, 2011 at 6:11 PM, Hector Santos wrote: > Ah come on guys! We all know what the problems are, we know the sides > and what colors we wear. Is it possible to come up with a compromise > to solve this conflicts once and for all? > > Dave, don't you want receivers to follow RFC5585 design? If so, then > what can't we get the Outputs described for that design to work? From > what I can see, there are four variables: > > status REQUIRED > SDID REQUIRED, MANDATORY for Trust Identity Assessor (see 2.7) > AUID OPTIONAL, see 3.11 > ODID OPTIONAL for Checking Signing Process (see RFC5585) > > We have the REQUIRED/MANDATORY identity you want. But you have the > others too. > > What is technically wrong with this? > > -- > Sincerely > > Hector Santos > http://www.santronics.com ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
> this, but I need to get a clear view of consensus. Doug agrees with > Hector's note, below, and Dave and Murray do not. I'd like to hear > from others within the next few days, about whether you think we > should make the change Hector requests or not. Dave and Murray are right, Hector is not. R's, John ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.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 : DKIM And Mailing Lists
Author(s) : M. Kucherawy
Filename : draft-ietf-dkim-mailinglists-08.txt
Pages : 31
Date : 2011-04-27
DomainKeys Identified Mail (DKIM) allows an administrative mail
domain (ADMD) to assume some responsibility for a message. Based on
deployment experience with DKIM, this Best Current Practices document
provides guidance for the use of DKIM with scenarios that include
Mailing List Managers (MLMs). {DKIM 12}
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dkim-mailinglists-08.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.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
Hi, Murray, On 5/6/11 8:50 PM, Murray S. Kucherawy wrote: >> -Original Message- >> From: John R. Levine [mailto:jo...@iecc.com] >> Sent: Friday, May 06, 2011 11:43 AM >> To: Murray S. Kucherawy >> Cc: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output >> > +--+--+ > | count(*) | mailing_list | > +--+--+ > |77246 |0 | > |78853 |1 | > +--+--+ That's just strange. Most of the l= signatures don't cover the whole body, and half of those didn't go through a mailing list? >>> I suspect it's use of "l=" by a signer without regard to whether or not >>> the mail is heading to an MLM. For example, OpenDKIM's antecedent had >>> that as an option; only the evolution to OpenDKIM allowed you to be more >>> specific. >> Except that doesn't explain why l= doesn't cover the entire body. >> >> Signing or verifying bug? Clever spammer replaying signed mail and >> getting away with it? Forwarders of some sort that add a footer but >> otherwise don't look like mailing lists? > My guess is the third one. The specification for what we decide is a mailing > list submission isn't bulletproof, but is listed as: > > - has a "Precedence: list" field > - has a "List-Id: field > - has a "List-Post:" field > - has a "List-Unsubscribe:" field > - has a "Mailing-List:" field I assume this is a boolean OR list? /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl] > Sent: Friday, May 06, 2011 1:48 PM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > > My guess is the third one. The specification for what we decide is a > > mailing list submission isn't bulletproof, but is listed as: > > > > - has a "Precedence: list" field > > - has a "List-Id: field > > - has a "List-Post:" field > > - has a "List-Unsubscribe:" field > > - has a "Mailing-List:" field > > I assume this is a boolean OR list? Correct. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] I-D ACTION:draft-ietf-dkim-rfc4871bis-09.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 : DomainKeys Identified Mail (DKIM) Signatures Author(s) : D. Crocker, et al Filename : draft-ietf-dkim-rfc4871bis-09.txt Pages : 75 Date : 2011-05-01 DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay or one of their agents. DKIM separates the question of the identity of the signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and querying the signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC4871 and RFC5672. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dkim-rfc4871bis-09.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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
On 5/6/11 8:43 PM, John R. Levine wrote: +--+--+ | count(*) | mailing_list | +--+--+ |77246 |0 | |78853 |1 | +--+--+ >>> That's just strange. Most of the l= signatures don't cover the whole >>> body, and half of those didn't go through a mailing list? >> I suspect it's use of "l=" by a signer without regard to whether or not >> the mail is heading to an MLM. For example, OpenDKIM's antecedent had >> that as an option; only the evolution to OpenDKIM allowed you to be more >> specific. > Except that doesn't explain why l= doesn't cover the entire body. > > Signing or verifying bug? Clever spammer replaying signed mail and > getting away with it? Forwarders of some sort that add a footer but > otherwise don't look like mailing lists? or just "authoring MLM's" (see par. 4.2 of http://www.ietf.org/id/draft-ietf-dkim-mailinglists-08.txt) which probably use software that incorporates some (minimalistic) type of MLM which adds one of the headers, listed by Murray. I notice I regularly get mail from marketing departments of my car dealer, smart phone provider, from Adobe, etc. that carry a 'List-Unsubscribe' header and some of them carry a Precedence header. I wouldn't be surprised if the percentage of this type of messages is greater than the percentage of the 'classic' re-sending MLM type of messages. Back to the topic of this thread: I don't think we can draw any conclusions from these statistics in relation to the description of l= in rfc4871bis. The current description in rfc4871bis works for me. /rolf ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output
Rolf E. Sonneveld wrote: > Back to the topic of this thread: I don't think we can draw any > conclusions from these statistics in relation to the description of l= > in rfc4871bis. The current description in rfc4871bis works for me. I would like to know the percentage of l=xxx where xxx equals actual body count. If its very high, that will tell me there are many references to "l=" with text that sounds like its expected to be added. I posted this here: http://mipassoc.org/pipermail/ietf-dkim/2011q2/016138.html So if we wish to discourage "l=" useful, some of these text needs to be reworded, like this one in section 3.5 bh= The hash of the canonicalized body part of the message as limited by the "l=" tag (base64; REQUIRED). It sounds like its expected and the REQUIRED is too close to "l=" which can throw someone off. I suggested the change to be: bh= The hash (base64; REQUIRED) of the canonicalized body part of the message. It is limited to the entire body length count or length explicitly set with the optional "l=" tag count value. If the hash is to represent the entire body with no expectation for additional unhashed text appended to the body, the l= tag SHOULD NOT be used. (See Section 9.1). My post list all the references to "l=" for reading and setting. -- 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] l= statistics was 23 again (sorry John) was Output
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Hector Santos > Sent: Friday, May 06, 2011 3:33 PM > To: Rolf E. Sonneveld > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output > > Rolf E. Sonneveld wrote: > > > Back to the topic of this thread: I don't think we can draw any > > conclusions from these statistics in relation to the description of l= > > in rfc4871bis. The current description in rfc4871bis works for me. > > I would like to know the percentage of l=xxx where xxx equals actual > body count. Assuming you mean "percentage of signatures using 'l=' where the signed length and the message length are the same", OpenDKIM's data shows that as 9008 out of 156524, or less than 6%. Absent an error in the data, that suggests to me that when "l=" is used, it's being used because the mail is following a path through which it is likely to be extended. > So if we wish to discourage "l=" useful, some of these text needs to > be reworded, like this one in section 3.5 [...] I don't think the proposed text adds or clarifies anything that isn't already there. The semantics and use of "l=" are pretty well defined already. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt
Sorry if I jump in, some comments:
4.3 it would be nice to talk about message encoding change like QP->8bits,
may be in minor or major body changes. It is a minor change for the human
but major for the machines as many characters got changed.
5.1 "Some mail filtering software incorrectly penalizes a message
containing a DKIM signature that fails verification." You should
remind/add that a message that fails DKIM must be considered like having
no signature at all. Then you can bring ADSP, policy in the picture, and
there ADSP too will not make the difference if a message has no signature
or a failed signature. I have the feeling that making the point clears
helps in building message policies (out of scope of this document).
"such as a signing and author subdomain {DKIM 12}" -> "such as a signing
and author subdomain {DKIM 12} or a totally different domain"
5.2 There are some professional services that allows to look in to
reception at some providers
5.3 postmaster should inform their users that messages are likely to be
discarded if sent via a MLM.
6.8 talk about headers to add to the message but do not talk which
recommended headers should be signed. They are specified in DKIM 5.5 but
would be nice to do a reminder here specific to MLM.
Speaking of DKIM 5.5, List- headers are recommended to be signed, but
doesn't it creates confusion? My feel is that they should be signed only
if present in the message, if they are not present DKIM should not mention
them in h= at all.
On 5/7/11 6:30 , "internet-dra...@ietf.org"
wrote:
>draft-ietf-dkim-mailinglists-08
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
