Re: [ietf-dkim] More on layer violations
On Oct 21, 2010, at 11:01 AM, Steve Atkins wrote: > On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote: >> >> >> Take a tour through the eleven parts of Section 7 of RFC5451, and then >> Appendices A and C. They provide all kinds of warnings about >> misinterpreting the data provided, which amounts to pretty firm >> implementation advice, and identifies ways you can shoot yourself in the >> foot. But none of those sections are normative. (Actually there are two >> SHOULDs in 7.4, but in retrospect they shouldn't really be there.) >> >> That's what I'm advocating here: The normative stuff defines the core >> mechanics of the protocol itself, and the informative stuff explains why >> it's done that way, detailed implementation advice including stuff about >> other layers, and how one should (and shouldn't) interpret the output. > > +1 +1 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
-1. This is not a LAYER violation. DKIM is a protocol for RFC 822/2822/5322 data to: a) verify a message signature, and/or b) create a message signature. In order to do either requires INPUT that MUST be valid for the protocol to be fundamentally correct with its OUTPUT. Therefore it MUST make sure its input is 100% valid. This is not different than any function generator that checks its boundary conditions. A robust function generator MUST check its input otherwise you have faults, chaos, aborts, GIGO - Garbage In, Garbage Out. DKIM is fundamentally a security protocol and it will be insane to believe that it should allow GIGO to occur due to not checking it input validity. A Layer Violation is when you are asking for data bits that in 821/2821/5321 (or another our feed) and/or also producing BITS that other layers like a MUA might use. We are not doing the former but would be if we bind bits like a Return-Path. We are differently doing the latter with the creating of more bits for other LAYERS to use. DKIM validating its INPUT is not a layer violation and in practice, it will be extremely bad product engineering. In fact, I would go as far to make it an ethical engineering responsibility for ALL DKIM components to make sure its not a GIGO engine. Now, if that doesn't jive with the "IETF DOCS" well, thats an entirely different issue. Most implementators are not going to GAS (Give a S$$$) what that docs says or doesn't say if it not providing what is fundamentally necessary. The DKIM component MUST check its input and at least one independent API has done so (on the verify side for 5322.From only). It could not pass the buck to 822/2822/5322 message generators or verifiers. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com Murray S. Kucherawy wrote: > You can add OpenDKIM to that list. Like I said, it already does do the > validation, but that's because RFC5322 says so, not because RFC4871 says so. > And I think that's the way it should stay. > > Take a tour through the eleven parts of Section 7 of RFC5451, and then > Appendices A and C. They provide all kinds of warnings about misinterpreting > the data provided, which amounts to pretty firm implementation advice, and > identifies ways you can shoot yourself in the foot. But none of those > sections are normative. (Actually there are two SHOULDs in 7.4, but in > retrospect they shouldn't really be there.) > > That's what I'm advocating here: The normative stuff defines the core > mechanics of the protocol itself, and the informative stuff explains why it's > done that way, detailed implementation advice including stuff about other > layers, and how one should (and shouldn't) interpret the output. > > > ___ > 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] More on layer violations
On Oct 21, 2010, at 9:53 AM, Murray S. Kucherawy wrote: > > > Take a tour through the eleven parts of Section 7 of RFC5451, and then > Appendices A and C. They provide all kinds of warnings about misinterpreting > the data provided, which amounts to pretty firm implementation advice, and > identifies ways you can shoot yourself in the foot. But none of those > sections are normative. (Actually there are two SHOULDs in 7.4, but in > retrospect they shouldn't really be there.) > > That's what I'm advocating here: The normative stuff defines the core > mechanics of the protocol itself, and the informative stuff explains why it's > done that way, detailed implementation advice including stuff about other > layers, and how one should (and shouldn't) interpret the output. +1 Cheers, Steve ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
Re: [ietf-dkim] More on layer violations
> -Original Message- > From: John R. Levine [mailto:jo...@iecc.com] > Sent: Thursday, October 21, 2010 9:07 AM > To: Murray S. Kucherawy > Cc: ietf-dkim@mipassoc.org > Subject: More on layer violations > > Having pondered the layer thing some more, it occurs to me that we have > several decades of practice with software that validates the format of > mail messages to a greater or lesser extent, with the emphasis on lesser. > Different software depends on different bits of the message to be correct, > which means that some leakage of the message validation into different > applications is unavoidable unless you're willing to lose mail that has > flaws that don't matter to the applications that it passes through. > > In procmail, for example, doubled subjects only matter if you have a rule > that does something depending on the subject line. In MUAs, based on the > random way existing MUAs handle them, they don't matter at all. All true. But those are implementations, not specifications. You can add OpenDKIM to that list. Like I said, it already does do the validation, but that's because RFC5322 says so, not because RFC4871 says so. And I think that's the way it should stay. Take a tour through the eleven parts of Section 7 of RFC5451, and then Appendices A and C. They provide all kinds of warnings about misinterpreting the data provided, which amounts to pretty firm implementation advice, and identifies ways you can shoot yourself in the foot. But none of those sections are normative. (Actually there are two SHOULDs in 7.4, but in retrospect they shouldn't really be there.) That's what I'm advocating here: The normative stuff defines the core mechanics of the protocol itself, and the informative stuff explains why it's done that way, detailed implementation advice including stuff about other layers, and how one should (and shouldn't) interpret the output. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
[ietf-dkim] More on layer violations
Having pondered the layer thing some more, it occurs to me that we have several decades of practice with software that validates the format of mail messages to a greater or lesser extent, with the emphasis on lesser. Different software depends on different bits of the message to be correct, which means that some leakage of the message validation into different applications is unavoidable unless you're willing to lose mail that has flaws that don't matter to the applications that it passes through. In procmail, for example, doubled subjects only matter if you have a rule that does something depending on the subject line. In MUAs, based on the random way existing MUAs handle them, they don't matter at all. So that's where my SHOULD NOT comes from. It leaks the bit that matters to DKIM. 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
