Re: [ietf-dkim] MLM and C14N
Barry Leiba wrote: >> Do you know what is being asked? > >> A real live LIST organism (stream) is adding an extra line (two bytes, >> ) after the header and before the body probably all its life > > It's an outlier, off in the weeds. This is not a common situation all > around the Internet. And in any case, the MLM document isn't the > place to define a new algorithm. I winged out two things; mentioning the MLM behavior which is real, live, current and if you like, a recommendation a "kludge" for verifiers to consider. I already said I don't like kludges, but I fail to see why it can't be mentioned that MLM exists that can add the extra line. Minor body changes: Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, or of list policy, etc, including some lists adding an extra line after the header and before the body. > Six. I also disagree. Fine, but did you ever see the movie "12 Angry Men?" :) No, I have no interesting continuing this but for the record, I do find it very inconsistent to ignore a real scenario for an MLM I-D who's main purpose is to provide information about the real MLM/DKIM incompatibility issues and intentionally wants to hide this insight that could promote changes. -- 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] MLM and C14N
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of Barry Leiba > Sent: Sunday, May 15, 2011 7:56 PM > To: Hector Santos > Cc: DKIM List > Subject: Re: [ietf-dkim] MLM and C14N > > > Do you know what is being asked? > > 1. We didn't want more than one or two. This obviously never did nor > never should take precedence over a true need for another one, but the > idea is that the bar needs to be very high for a new one. The > combinatorics get messy. > > 2. We wanted to cover the vast majority of the cases, though we knew > there'd always be outlying situations where some mail would get broken > because what we had didn't *quite* cover some other case. We decided > to accept that. > > 3. We absolutely did *not* want to go adding new algorithms for this > or that piece of software that was getting something wrong. > Canonicalization algorithms were *not* designed to work around broken > software. They're meant to deal primarily with legitimate, if > sometimes unfortunate, changes that get made to the mail along the > way, and secondarily with *very common* situations that creep into the > questionable area. I would add that adding a new canonicalization now has an extremely high cost to the people that want to use it, because signatures using it will go unverified for a very long time until software supporting the new canonicalization is widely deployed. We shouldn't underestimate what all of that means just to handle one or two corner cases that are actually more likely broken software than an actual universal problem mandating a protocol extension. The same goes for new signing algorithms. ECC, whenever DKIM is extended to cover it, will be an interesting experiment. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
> Do you know what is being asked? I think everyone understands what you're asking. They just disagree, and so do I. When all this started, before DKIM came to the IETF, and then again afterward, we spent a *lot* of time looking at the canonicalization algorithms -- and they were changed a bit after the work came into the IETF. We didn't come by them casually. Throughout it, there were a few goals in choosing canonicalization algorithms: 1. We didn't want more than one or two. This obviously never did nor never should take precedence over a true need for another one, but the idea is that the bar needs to be very high for a new one. The combinatorics get messy. 2. We wanted to cover the vast majority of the cases, though we knew there'd always be outlying situations where some mail would get broken because what we had didn't *quite* cover some other case. We decided to accept that. 3. We absolutely did *not* want to go adding new algorithms for this or that piece of software that was getting something wrong. Canonicalization algorithms were *not* designed to work around broken software. They're meant to deal primarily with legitimate, if sometimes unfortunate, changes that get made to the mail along the way, and secondarily with *very common* situations that creep into the questionable area. > A real live LIST organism (stream) is adding an extra line (two bytes, > ) after the header and before the body probably all its life It's an outlier, off in the weeds. This is not a common situation all around the Internet. And in any case, the MLM document isn't the place to define a new algorithm. > This is surreal. Don't shoot the messenger, listen to the message! There's nothing surreal here, and, again, I ask you to stop being extreme and inflammatory. Calm discussion, please. Anyway, we *are* listening to the message. It seems that at least five people have listened, and responded. Their response is simply one of disagreement. Listening is not the same as agreeing. Six. I also disagree. Barry ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Do you know what is being asked? A real live LIST organism (stream) is adding an extra line (two bytes, ) after the header and before the body probably all its life and this new "thing," this new document called: DKIM And Mailing Lists has no interest in adding another note in section 3.3 titled "Current MLM Effects On Signatures" regarding a real living, walking and running MLM behavior? This is surreal. Don't shoot the messenger, listen to the message! -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Dave Crocker wrote: > +1. No. > > "John R. Levine" wrote: > > >>> No. >> +1 to the No. > > ___ > 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] MLM and C14N
+1. No. "John R. Levine" wrote: >> No. > >+1 to the No. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Murray S. Kucherawy wrote: >> Isn't that what you are doing in this MLM I-D, creating a DKIM >> "protocol extension" for MLMs? > > No, that's not what that document does. At the end of the day, this document is describing incompatibility issues and provide "suggestions" (remember it is suggestions not a mandate) in how (via protocol methods changes, administrative protocol setups, etc) with an idealized goal to minimize the impact of the incompatibility issues. If that is not what it does, what does it do for its potential audience of? - DKIM signer developer - MLM developer, - DKIM verifier developer What does one get out of this document? -- 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] MLM and C14N
SM wrote: > Hi Hector, > At 21:40 14-05-2011, Hector Santos wrote: >> Can't share the wisdom why? > > It's merely an opinion. Please see Murray's comment about a slippery > slope. I understand the point. But we are doing all this already like section 3.3 Current MLM Effects On Signatures; Minor body changes. It says: Minor body changes: Some lists prepend or append a few lines to each message to remind subscribers of an administrative URL for subscription issues, or of list policy, etc. The sentence can include or be extended: In addition, some list changes are not obvious and may be just an extra line between the header and start of the body. This a MLM mail integrity deviation just like all the other obscure MLM mail integrity issues we can have. I personally would like to extend it to say: This is an C14N issue that is out of scope but its possible invalid signatures can be valid when the extra line is removed from the hashing. Again, this is a real live MLM stream scenario. Why doesn't anyone care about addressing these types of MLM streams? This is suppose to be an informative guide about the issues retrofitting an MLM with DKIM. Not the other way around. Why not provide the insights, all the issues and let the verifier decide? Why not let the MLM developer learn what his software might be doing so he might fix it? -- 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] MLM and C14N
On May 15, 2011, at 8:44 AM, John R. Levine wrote: >> Hi Hector, >> At 15:20 14-05-2011, Hector Santos wrote: >>> Shouldn't the MLM I-D say something regarding C14N and CR/LF related >>> mutations? >> >> No. > > +1 to the No. +1 to the No. -- J.D. Falk the leading purveyor of industry counter-rhetoric solutions ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Hi Hector, At 21:40 14-05-2011, Hector Santos wrote: >Can't share the wisdom why? It's merely an opinion. Please see Murray's comment about a slippery slope. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
> -Original Message- > From: Hector Santos [mailto:hsan...@isdg.net] > Sent: Sunday, May 15, 2011 9:25 AM > To: Murray S. Kucherawy > Cc: DKIM List > Subject: Re: [ietf-dkim] MLM and C14N > > > This is a software problem, > > You mean the MLM who is ignorant of DKIM meta data for the past "40 > years?" Yes, that's what I mean. > > not something that needs to be solved by creating a protocol > extension. > > Isn't that what you are doing in this MLM I-D, creating a DKIM > "protocol extension" for MLMs? No, that's not what that document does. Creating a new canonicalization is a protocol extension. It creates a slippery slope wherein we are constantly creating or adjusting canonicalization algorithm(s) to deal with new cases we find and want to accommodate. It's a bad idea. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
Murray S. Kucherawy wrote: >> -Original Message- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of John R. Levine >> Sent: Sunday, May 15, 2011 6:44 AM >> To: SM >> Cc: DKIM List >> Subject: Re: [ietf-dkim] MLM and C14N >> >>> Hi Hector, >>> At 15:20 14-05-2011, Hector Santos wrote: >>>> Shouldn't the MLM I-D say something regarding C14N and CR/LF related >>>> mutations? >>> No. >> +1 to the No. > > +1 to the No. > > This is a software problem, You mean the MLM who is ignorant of DKIM meta data for the past "40 years?" > not something that needs to be solved by creating a protocol extension. Isn't that what you are doing in this MLM I-D, creating a DKIM "protocol extension" for MLMs? IMV, this MLM I-D is 100% about a MLM and VERIFIER mail integration protocol inconsistency, i.e. software problems, in dictating whats MLM and Verifier Software need to be considered and change to retrofit DKIM and ADSP into a MLM and MLM related issues with verifiers. IMV, the issue equally falls in the same MLM chaotic environment in how there long legacy behavior and different ways it can break transparent meta data we call DKIM. The extra preexisted DKIM - we can tell these software to not do this or that for the sake of DKIM, but is that realistic? I don't think so - the burden is on 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] MLM and C14N
> -Original Message- > From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] > On Behalf Of John R. Levine > Sent: Sunday, May 15, 2011 6:44 AM > To: SM > Cc: DKIM List > Subject: Re: [ietf-dkim] MLM and C14N > > > Hi Hector, > > At 15:20 14-05-2011, Hector Santos wrote: > >> Shouldn't the MLM I-D say something regarding C14N and CR/LF related > >> mutations? > > > > No. > > +1 to the No. +1 to the No. This is a software problem, not something that needs to be solved by creating a protocol extension. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] MLM and C14N
John R. Levine wrote: >> Hi Hector, >> At 15:20 14-05-2011, Hector Santos wrote: >>> Shouldn't the MLM I-D say something regarding C14N and CR/LF related >>> mutations? >> No. > > +1 to the No. > > I have my reservations about the draft, but this is not one of them. In general, I would say NO too because I don't like kludges. My point is that the draft is already peppered with scenarios about how MLM can break things and it properly classifies the known simple "list-like" type of "alias" address expanders that in general, the messages is not altered. Of course, we all know its not the only kind; a real List Server always provides list admin options to not alter things like the IETF-SMTP list seems to be been setup (with mailman?). But here, it appears it does add a extra after the headers. So my question is about whether we should provide an "informative implementator" insight that there may be an extra generated by non-DKIM aware list. It can make all the difference in a valid versus invalid DKIM signed submission to a non-DKIM aware MLM, which BTW, I did add logic to my verifier to check for this extra when a BODY_HASH error first occurs and redo the hash without it. It works! But I am probably going to add a condition based on LIST-ID to enable this check. I fail to see why we would not be interested in giving verifiers some insight into this real live scenario. Is it because its a more general DKIM issue and ideally belongs in RFC4671bis (too late)? -- 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] MLM and C14N
> Hi Hector, > At 15:20 14-05-2011, Hector Santos wrote: >> Shouldn't the MLM I-D say something regarding C14N and CR/LF related >> mutations? > > No. +1 to the No. I have my reservations about the draft, but this is not one of them. 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] MLM and C14N
SM wrote: > Hi Hector, > At 15:20 14-05-2011, Hector Santos wrote: >> Shouldn't the MLM I-D say something regarding C14N and CR/LF related >> mutations? > > No. Can't share the wisdom why? >> I hate kludges but the insight for interested DKIM verifiers may help >> increase valid signatures coming from Aliasing list streams with >> slight CR/LR mutations. > > I doubt that the example you are referring to is an "Aliasing" list stream. Just going by what the MLM I-D used for a "no change" MLM classification, i.e. a basic address expander. -- 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] MLM and C14N
Hi Hector, At 15:20 14-05-2011, Hector Santos wrote: >Shouldn't the MLM I-D say something regarding C14N and CR/LF related >mutations? No. >I hate kludges but the insight for interested DKIM verifiers may help >increase valid signatures coming from Aliasing list streams with >slight CR/LR mutations. I doubt that the example you are referring to is an "Aliasing" list stream. Regards, -sm ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] MLM and C14N
SM, Shouldn't the MLM I-D say something regarding C14N and CR/LF related mutations? For example, it can say something in: - Section 3.2 for the Aliasing MLM type - Section 3.3 for the Minor Body Changes possibility. Maybe something in one of the handling sections: Verifications of list messages resulting with an invalid body hash MAY check to see if there is an extra line between the message headers and the body and retry the body hash verification with the line stripped. I hate kludges but the insight for interested DKIM verifiers may help increase valid signatures coming from Aliasing list streams with slight CR/LR mutations. -- HLS Hector Santos wrote: > SM wrote: >> Hi Hector, >> At 15:23 13-05-2011, Hector Santos wrote: >>> I am wondering if anyone else can confirm BODY HASH errors with the >>> originating author domain DKIM signature mail submitted to the >>> IETF-SMTP fora. >> Yes. It may be an extra line between the message headers and the body. > > Visually comparing the sent message versus the one echoed back by the > list, that seems to be the case. Checking into this, I see that I > discovered this issue back in 2006 and wrote this I-D proposing a new > C14N method called STRIP. > > http://tools.ietf.org/html/draft-santos-dkim-strip-00 > > Abstract > > The DKIM base protocol has offers two digital signature > canonicalization (cl4n) methods called "relaxed" and "simple" with > low reliability and survivability during in-transient operations. > This proposal describes a new STRIP canonicalization algorithm and > method to increase the reliability and survivability of the digital > signature. In additional, the proposal describe new original body > hashing requirements to help secure STRIP c14n security concerns > found in a similar but deprecated NOFWS c14n method. > > From the 1.0 introduction: > > > > This documents introduces the new STRIP c14n which is similar to > RELAXED but with the added logic to remove all CR and LF characters > from the hashing engine. The STRIP c14n is very similar to the NOFWS > c14n method used by Yahoo's experimental DomainKeys protocol and was > once considered for usage for the DKIM protocol. However, since it > was determined the NOFWS c14n exhibited some replay security threats, > it is expected for STRIP c14n to also inherent the same security > concerns. > > The security concern stated in the final sentence were addressed in > this proposal. > ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
