From paf at cisco.com Thu Dec 16 08:31:29 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 16 Dec 2004 08:31:29 +0100 Subject: [massanity] Re: Initial thoughts from Nathaniel In-Reply-To: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> References: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> Message-ID: <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> I have not heard much from other people than Nathaniel on this MIME or non-MIME issue. Is it the case (a) you don't care (b) don't have time or (c) it doesn't matter? I have seen more evidence for example Cisco marketing pushing non-MIME format very very hard, and if we don't have any arguments why signing MIME-structured bodies of SMTP messages is technically broken, that is what will happen. What I saw today is that (of course) the Outlook client is structured internally in a way so it handle only MIME-parts. To get the raw data, one have to fight very hard (if at all possible). So, a request might go to Microsoft to change the client to NOT be as MIME-aware as it is today. This because the whole body have to be treated as an opaque blob. I feel I have been fighting for 10 years no for more MIME support, and I don't understand how the technical community (IETF) can accept now email taking a step back in evolution towards non-MIME mechanisms. Without ESMTP negotiation abilities that imply changes of RFC2822 body content (but still intact content after MIME parsing). Please, spend some 10-20 seconds on this, and let me know what you all think. paf On Nov 14, 2004, at 11:54, Patrik F?ltstr?m wrote: >> I'm afraid you lose me at step a): >> >> On Nov 11, 2004, at 8:03 PM, massanity-request at lists.paf.se wrote: >> >>> (a) I don't believe we will be able to have two ways of signing >>> message bodies in the long run. Either we have multipart/signed, or >>> sign the bucket of bits in the message (and ignore the MIME. We will >>> never be able to have both >> >> This is not a belief that I share. There are *lots* of things we >> have two ways of doing, why predict that this won't be another one? > > Because they technically are very very hard to implement at the same > time. Sure, if we had two ways of doing the same thing that could > coexist I would not be so nervous, but I don't think it is possible > for these things. Just think of the transformations of the body of a > message multipart/signed can create. Or what transformations 8BITMIME > can create. > > I.e. all of our thinking in SMTP land since 1995 has been to protect > the MIME structure and have the MIME structure not be damaged. Now > with MASS initiatives, we once again are back to "don't change the > bytes in the body". > > But, this is exactly what I want to discuss with you who know SMTP at > least as well as I do (in many cases much much better). > >> More important, I don't think *either* of these two is the way most >> of us have been looking at doing MASS signatures. I think we're >> working on a third model here, one I would characterize for lay >> audiences as a "low-resolution signature" (by analogy to low-res >> graphics). Think of it not as a cryptographically signed message, >> but a cryptographically signed *checksum* of the message, using a >> checksum algorithm that is invariant across the kinds of whitespace >> shifting and line wrapping that characterizes email transport. > > Correct, there is a difference between the canonicalization of the > message body itself, and what we pass to the hash function that > calculates the signature. But, for example, is it correct to do this > function so low-rez that it don't alarm when certain changes happen? I > have seen ideas that for example strip 8th bit on bytes in the body, > ignore what the has function "think" is a boundary between multipart > messages (as the last boundary has '--' appended), and byte counters > for how many bytes in the message is to be signed. Etc. > > The problem is that the checksum algorithm will be so low-rez, and > still not work (due to added multipart-wrappers around existing > messages, and changes in content-transfer-encoding during flight) that > it will not fly. > > For example, I see too much of such issues with the Cisco idea, IIM. > Every day there is a new "fun" problem. > >>> (b) If we sign the bucket of bits, we destroy the ability to use >>> 8BIT content-transfer-encoding and the 8BITMIME ESMTP extension >>> (that lead to encoding of messages during flight in some cases). >> >> This is the sort of issue we're still grappling with. My current >> theory is that the "checksum" should be computed on a canonicalized >> version of the message that undoes all transport encodings and >> perhaps even ignores the purely syntactic elements of the MIME >> structure (e.g. the boundary line) > > So, how are we supposed to handle the case where MTA's do add > multipart/signature wrappers already today? That add a > multipart/signature wrapper around the message as we have it today. > Are we 100% sure the unwrapping will leave exactly the same number of > bytes (and the same bytes) at the other end of the "tunnel"? > > I am so nervous we are optimizing either for old crap systems that can > not handle MIME or for the new ones that do the right thing. That we > can not do both, and that we will choose to optimize for the systems > that are old and broken. > >> Does this help at all? -- Nathaniel > > Yes, it is exactly the correct direction to go with this discussion. > > paf > From galvin at elistx.com Thu Dec 16 16:20:18 2004 From: galvin at elistx.com (James M Galvin) Date: Thu, 16 Dec 2004 10:20:18 -0500 Subject: [massanity] Re: Initial thoughts from Nathaniel In-Reply-To: <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> References: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> Message-ID: So, here's my 20 seconds. I care, my time is limited, and it does matter. :-) The 20 second summary is: Protecting content, for any definition of protection, should not be confused with protecting the transfer. The services could be related but they should not be designed in such a way as to require a relationship. Some high-level thoughts for those with more than 20 seconds: I don't believe we can protect the content of a message without MIME and I further don't believe we should pursue solutions that attempt to achieve this. Some would argue this is catering to old transfer systems that munge messages but without MIME you have to have solve the problems that MIME solves anyway. Even with 8BIT transport there will sooner or later be a downgrade, for a very long time. Some would argue this is catering to no one, since multipart/signed is not supported correctly as broadly as we would like. I think we should re-affirm the significance of multipart/signed by using it as building block for other solutions, because it is the right thing to do. My problem with MARID, in the end since I started out being very supportive, is that the scope of the problem kept getting larger. The solutions were ultimately just too complicated and I was relieved it "failed." In the large, it simply did not maintain a clear separation between protecting content and protecting transfer. My problem with MASS is that it keeps creeping into wanting to sign an email message, i.e., creating a new secure email protocol. The only reason I see for *MAYBE* supporting such a thing is the fact that multipart/signed is just not well-supported, but see above. Insofar as the goal of MASS is to affirm each that each hop along a delivery path is authorized to transfer a message, I'm 100% in support of it. This desire to do something end-to-end worries me because I don't see what it achieves that is not already available with the protocols we have today. And the argument that people haven't implemented them in 10 years so we need something different is a red herring. There are toolkits out there so I'm not convinced it's any more difficult than implementing something completely new. And it's certainly less certain that a new implementation will work any better than a toolkit that has stood for some "test of time". So, all this is a bit high-level but you asked what I'm thinking and that's it. Jim --On Thursday, December 16, 2004 8:31 AM +0100 Patrik F?ltstr?m wrote: > I have not heard much from other people than Nathaniel on this MIME > or non-MIME issue. > > Is it the case (a) you don't care (b) don't have time or (c) it > doesn't matter? > > I have seen more evidence for example Cisco marketing pushing > non-MIME format very very hard, and if we don't have any arguments > why signing MIME-structured bodies of SMTP messages is technically > broken, that is what will happen. > > What I saw today is that (of course) the Outlook client is structured > internally in a way so it handle only MIME-parts. To get the raw > data, one have to fight very hard (if at all possible). So, a request > might go to Microsoft to change the client to NOT be as MIME-aware as > it is today. This because the whole body have to be treated as an > opaque blob. > > I feel I have been fighting for 10 years no for more MIME support, > and I don't understand how the technical community (IETF) can accept > now email taking a step back in evolution towards non-MIME > mechanisms. Without ESMTP negotiation abilities that imply changes of > RFC2822 body content (but still intact content after MIME parsing). > > Please, spend some 10-20 seconds on this, and let me know what you > all think. > > paf > > On Nov 14, 2004, at 11:54, Patrik F?ltstr?m wrote: > > >> I'm afraid you lose me at step a): > >> > >> On Nov 11, 2004, at 8:03 PM, massanity-request at lists.paf.se wrote: > >> > >>> (a) I don't believe we will be able to have two ways of signing > >>> message bodies in the long run. Either we have multipart/signed, > >>> or sign the bucket of bits in the message (and ignore the MIME. > >>> We will never be able to have both > >> > >> This is not a belief that I share. There are *lots* of things we > >> have two ways of doing, why predict that this won't be another one? > > > > Because they technically are very very hard to implement at the > > same time. Sure, if we had two ways of doing the same thing that > > could coexist I would not be so nervous, but I don't think it is > > possible for these things. Just think of the transformations of > > the body of a message multipart/signed can create. Or what > > transformations 8BITMIME can create. > > > > I.e. all of our thinking in SMTP land since 1995 has been to > > protect the MIME structure and have the MIME structure not be > > damaged. Now with MASS initiatives, we once again are back to > > "don't change the bytes in the body". > > > > But, this is exactly what I want to discuss with you who know SMTP > > at least as well as I do (in many cases much much better). > > > >> More important, I don't think *either* of these two is the way > >> most of us have been looking at doing MASS signatures. I think > >> we're working on a third model here, one I would characterize for > >> lay audiences as a "low-resolution signature" (by analogy to > >> low-res graphics). Think of it not as a cryptographically signed > >> message, but a cryptographically signed *checksum* of the > >> message, using a checksum algorithm that is invariant across the > >> kinds of whitespace shifting and line wrapping that characterizes > >> email transport. > > > > Correct, there is a difference between the canonicalization of the > > message body itself, and what we pass to the hash function that > > calculates the signature. But, for example, is it correct to do > > this function so low-rez that it don't alarm when certain changes > > happen? I have seen ideas that for example strip 8th bit on bytes > > in the body, ignore what the has function "think" is a boundary > > between multipart messages (as the last boundary has '--' > > appended), and byte counters for how many bytes in the message is > > to be signed. Etc. > > > > The problem is that the checksum algorithm will be so low-rez, and > > still not work (due to added multipart-wrappers around existing > > messages, and changes in content-transfer-encoding during flight) > > that it will not fly. > > > > For example, I see too much of such issues with the Cisco idea, > > IIM. Every day there is a new "fun" problem. > > > >>> (b) If we sign the bucket of bits, we destroy the ability to use > >>> 8BIT content-transfer-encoding and the 8BITMIME ESMTP extension > >>> (that lead to encoding of messages during flight in some cases). > >> > >> This is the sort of issue we're still grappling with. My current > >> theory is that the "checksum" should be computed on a > >> canonicalized version of the message that undoes all transport > >> encodings and perhaps even ignores the purely syntactic elements > >> of the MIME structure (e.g. the boundary line) > > > > So, how are we supposed to handle the case where MTA's do add > > multipart/signature wrappers already today? That add a > > multipart/signature wrapper around the message as we have it today. > > Are we 100% sure the unwrapping will leave exactly the same number > > of bytes (and the same bytes) at the other end of the "tunnel"? > > > > I am so nervous we are optimizing either for old crap systems that > > can not handle MIME or for the new ones that do the right thing. > > That we can not do both, and that we will choose to optimize for > > the systems that are old and broken. > > > >> Does this help at all? -- Nathaniel > > > > Yes, it is exactly the correct direction to go with this discussion. > > > > paf > > > > _______________________________________________ > massanity mailing list > massanity at lists.paf.se > http://lists.paf.se/cgi/listinfo/massanity From Chris.Newman at Sun.COM Sat Dec 18 02:33:25 2004 From: Chris.Newman at Sun.COM (Chris Newman) Date: Fri, 17 Dec 2004 17:33:25 -0800 Subject: [massanity] Re: Initial thoughts from Nathaniel In-Reply-To: References: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> Message-ID: I largely concur with James but would state it more strongly. If MASS is attempting to do object signing or end-to-end security, then it is a complete waste of time and deserves no IETF attention. We've tried this four times and have two failures and two partial successes. Software support for S/MIME is surprisingly widely deployed, but the PK infrastructure seems to be a show-stopper for actual use outside small enclaves. If we view the path a message takes through MTAs as follows: Submit -> *local hop -> MX domain hop -> *local hop -> message store then MASS should focus on protecting only the MX domain hop. If the scope for MASS is limited to that, then I consider it important and well worth our attention and I have no problem with it ignoring MIME structure (as content transformations can be deferred to the local hops). But as long as we're in the end-to-end security religion trap MASS will fail and we shouldn't waste time on it. - Chris James M Galvin wrote on 12/16/04 10:20 -0500: > So, here's my 20 seconds. I care, my time is limited, and it does matter. > :-) > > > The 20 second summary is: > > Protecting content, for any definition of protection, should not be confused > with protecting the transfer. The services could be related but they should > not be designed in such a way as to require a relationship. > > > Some high-level thoughts for those with more than 20 seconds: > > I don't believe we can protect the content of a message without MIME and I > further don't believe we should pursue solutions that attempt to achieve > this. Some would argue this is catering to old transfer systems that munge > messages but without MIME you have to have solve the problems that MIME > solves anyway. Even with 8BIT transport there will sooner or later be a > downgrade, for a very long time. > > Some would argue this is catering to no one, since multipart/signed is not > supported correctly as broadly as we would like. I think we should re-affirm > the significance of multipart/signed by using it as building block for other > solutions, because it is the right thing to do. > > > My problem with MARID, in the end since I started out being very supportive, > is that the scope of the problem kept getting larger. The solutions were > ultimately just too complicated and I was relieved it "failed." In the > large, it simply did not maintain a clear separation between protecting > content and protecting transfer. > > > My problem with MASS is that it keeps creeping into wanting to sign an email > message, i.e., creating a new secure email protocol. The only reason I see > for *MAYBE* supporting such a thing is the fact that multipart/signed is just > not well-supported, but see above. > > Insofar as the goal of MASS is to affirm each that each hop along a delivery > path is authorized to transfer a message, I'm 100% in support of it. This > desire to do something end-to-end worries me because I don't see what it > achieves that is not already available with the protocols we have today. > > And the argument that people haven't implemented them in 10 years so we need > something different is a red herring. There are toolkits out there so I'm > not convinced it's any more difficult than implementing something completely > new. And it's certainly less certain that a new implementation will work any > better than a toolkit that has stood for some "test of time". > > > So, all this is a bit high-level but you asked what I'm thinking and that's > it. > > Jim > > > > > --On Thursday, December 16, 2004 8:31 AM +0100 Patrik F?ltstr?m > wrote: > >> I have not heard much from other people than Nathaniel on this MIME >> or non-MIME issue. >> >> Is it the case (a) you don't care (b) don't have time or (c) it >> doesn't matter? >> >> I have seen more evidence for example Cisco marketing pushing >> non-MIME format very very hard, and if we don't have any arguments >> why signing MIME-structured bodies of SMTP messages is technically >> broken, that is what will happen. >> >> What I saw today is that (of course) the Outlook client is structured >> internally in a way so it handle only MIME-parts. To get the raw >> data, one have to fight very hard (if at all possible). So, a request >> might go to Microsoft to change the client to NOT be as MIME-aware as >> it is today. This because the whole body have to be treated as an >> opaque blob. >> >> I feel I have been fighting for 10 years no for more MIME support, >> and I don't understand how the technical community (IETF) can accept >> now email taking a step back in evolution towards non-MIME >> mechanisms. Without ESMTP negotiation abilities that imply changes of >> RFC2822 body content (but still intact content after MIME parsing). >> >> Please, spend some 10-20 seconds on this, and let me know what you >> all think. >> >> paf >> >> On Nov 14, 2004, at 11:54, Patrik F?ltstr?m wrote: >> >> >> I'm afraid you lose me at step a): >> >> >> >> On Nov 11, 2004, at 8:03 PM, massanity-request at lists.paf.se wrote: >> >> >> >>> (a) I don't believe we will be able to have two ways of signing >> >>> message bodies in the long run. Either we have multipart/signed, >> >>> or sign the bucket of bits in the message (and ignore the MIME. >> >>> We will never be able to have both >> >> >> >> This is not a belief that I share. There are *lots* of things we >> >> have two ways of doing, why predict that this won't be another one? >> > >> > Because they technically are very very hard to implement at the >> > same time. Sure, if we had two ways of doing the same thing that >> > could coexist I would not be so nervous, but I don't think it is >> > possible for these things. Just think of the transformations of >> > the body of a message multipart/signed can create. Or what >> > transformations 8BITMIME can create. >> > >> > I.e. all of our thinking in SMTP land since 1995 has been to >> > protect the MIME structure and have the MIME structure not be >> > damaged. Now with MASS initiatives, we once again are back to >> > "don't change the bytes in the body". >> > >> > But, this is exactly what I want to discuss with you who know SMTP >> > at least as well as I do (in many cases much much better). >> > >> >> More important, I don't think *either* of these two is the way >> >> most of us have been looking at doing MASS signatures. I think >> >> we're working on a third model here, one I would characterize for >> >> lay audiences as a "low-resolution signature" (by analogy to >> >> low-res graphics). Think of it not as a cryptographically signed >> >> message, but a cryptographically signed *checksum* of the >> >> message, using a checksum algorithm that is invariant across the >> >> kinds of whitespace shifting and line wrapping that characterizes >> >> email transport. >> > >> > Correct, there is a difference between the canonicalization of the >> > message body itself, and what we pass to the hash function that >> > calculates the signature. But, for example, is it correct to do >> > this function so low-rez that it don't alarm when certain changes >> > happen? I have seen ideas that for example strip 8th bit on bytes >> > in the body, ignore what the has function "think" is a boundary >> > between multipart messages (as the last boundary has '--' >> > appended), and byte counters for how many bytes in the message is >> > to be signed. Etc. >> > >> > The problem is that the checksum algorithm will be so low-rez, and >> > still not work (due to added multipart-wrappers around existing >> > messages, and changes in content-transfer-encoding during flight) >> > that it will not fly. >> > >> > For example, I see too much of such issues with the Cisco idea, >> > IIM. Every day there is a new "fun" problem. >> > >> >>> (b) If we sign the bucket of bits, we destroy the ability to use >> >>> 8BIT content-transfer-encoding and the 8BITMIME ESMTP extension >> >>> (that lead to encoding of messages during flight in some cases). >> >> >> >> This is the sort of issue we're still grappling with. My current >> >> theory is that the "checksum" should be computed on a >> >> canonicalized version of the message that undoes all transport >> >> encodings and perhaps even ignores the purely syntactic elements >> >> of the MIME structure (e.g. the boundary line) >> > >> > So, how are we supposed to handle the case where MTA's do add >> > multipart/signature wrappers already today? That add a >> > multipart/signature wrapper around the message as we have it today. >> > Are we 100% sure the unwrapping will leave exactly the same number >> > of bytes (and the same bytes) at the other end of the "tunnel"? >> > >> > I am so nervous we are optimizing either for old crap systems that >> > can not handle MIME or for the new ones that do the right thing. >> > That we can not do both, and that we will choose to optimize for >> > the systems that are old and broken. >> > >> >> Does this help at all? -- Nathaniel >> > >> > Yes, it is exactly the correct direction to go with this discussion. >> > >> > paf >> > >> >> _______________________________________________ >> massanity mailing list >> massanity at lists.paf.se >> http://lists.paf.se/cgi/listinfo/massanity > > > > _______________________________________________ > massanity mailing list > massanity at lists.paf.se > http://lists.paf.se/cgi/listinfo/massanity From paf at cisco.com Sat Dec 18 07:51:45 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sat, 18 Dec 2004 07:51:45 +0100 Subject: [massanity] Re: Initial thoughts from Nathaniel In-Reply-To: References: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> Message-ID: <4821F57E-50C1-11D9-88A0-000A95B2B926@cisco.com> I asked the people at Cisco working with the IIM proposal why they sign the body of a message, and I got the answer "to protect against replay attacks, where a signed message is grabbed, body changed, and then used as spam". Further, even though it protects only the MX hop, they claim the verification *can* be done end to end (verification in client) if the MTA doesn't support MASS verification. Also, they explicitly want the verification to survive what I would call two MX hops, where mailing list explosion is happening in between the two hops. So, what I see is (once again) that the list of "what problem are we solving" is missing. paf On Dec 18, 2004, at 02:33, Chris Newman wrote: > I largely concur with James but would state it more strongly. > > If MASS is attempting to do object signing or end-to-end security, > then it is a > complete waste of time and deserves no IETF attention. We've tried > this four > times and have two failures and two partial successes. Software > support for > S/MIME is surprisingly widely deployed, but the PK infrastructure > seems to be a > show-stopper for actual use outside small enclaves. > > If we view the path a message takes through MTAs as follows: > > Submit -> *local hop -> MX domain hop -> *local hop -> message store > > then MASS should focus on protecting only the MX domain hop. If the > scope for > MASS is limited to that, then I consider it important and well worth > our > attention and I have no problem with it ignoring MIME structure (as > content > transformations can be deferred to the local hops). But as long as > we're in > the end-to-end security religion trap MASS will fail and we shouldn't > waste > time on it. > > - Chris > > James M Galvin wrote on 12/16/04 10:20 -0500: > >> So, here's my 20 seconds. I care, my time is limited, and it does >> matter. >> :-) >> >> >> The 20 second summary is: >> >> Protecting content, for any definition of protection, should not be >> confused >> with protecting the transfer. The services could be related but they >> should >> not be designed in such a way as to require a relationship. >> >> >> Some high-level thoughts for those with more than 20 seconds: >> >> I don't believe we can protect the content of a message without MIME >> and I >> further don't believe we should pursue solutions that attempt to >> achieve >> this. Some would argue this is catering to old transfer systems that >> munge >> messages but without MIME you have to have solve the problems that >> MIME >> solves anyway. Even with 8BIT transport there will sooner or later >> be a >> downgrade, for a very long time. >> >> Some would argue this is catering to no one, since multipart/signed >> is not >> supported correctly as broadly as we would like. I think we should >> re-affirm >> the significance of multipart/signed by using it as building block >> for other >> solutions, because it is the right thing to do. >> >> >> My problem with MARID, in the end since I started out being very >> supportive, >> is that the scope of the problem kept getting larger. The solutions >> were >> ultimately just too complicated and I was relieved it "failed." In >> the >> large, it simply did not maintain a clear separation between >> protecting >> content and protecting transfer. >> >> >> My problem with MASS is that it keeps creeping into wanting to sign >> an email >> message, i.e., creating a new secure email protocol. The only reason >> I see >> for *MAYBE* supporting such a thing is the fact that multipart/signed >> is just >> not well-supported, but see above. >> >> Insofar as the goal of MASS is to affirm each that each hop along a >> delivery >> path is authorized to transfer a message, I'm 100% in support of it. >> This >> desire to do something end-to-end worries me because I don't see what >> it >> achieves that is not already available with the protocols we have >> today. >> >> And the argument that people haven't implemented them in 10 years so >> we need >> something different is a red herring. There are toolkits out there >> so I'm >> not convinced it's any more difficult than implementing something >> completely >> new. And it's certainly less certain that a new implementation will >> work any >> better than a toolkit that has stood for some "test of time". >> >> >> So, all this is a bit high-level but you asked what I'm thinking and >> that's >> it. >> >> Jim >> >> >> >> >> --On Thursday, December 16, 2004 8:31 AM +0100 Patrik F?ltstr?m >> wrote: >> >>> I have not heard much from other people than Nathaniel on this MIME >>> or non-MIME issue. >>> >>> Is it the case (a) you don't care (b) don't have time or (c) it >>> doesn't matter? >>> >>> I have seen more evidence for example Cisco marketing pushing >>> non-MIME format very very hard, and if we don't have any arguments >>> why signing MIME-structured bodies of SMTP messages is technically >>> broken, that is what will happen. >>> >>> What I saw today is that (of course) the Outlook client is structured >>> internally in a way so it handle only MIME-parts. To get the raw >>> data, one have to fight very hard (if at all possible). So, a request >>> might go to Microsoft to change the client to NOT be as MIME-aware as >>> it is today. This because the whole body have to be treated as an >>> opaque blob. >>> >>> I feel I have been fighting for 10 years no for more MIME support, >>> and I don't understand how the technical community (IETF) can accept >>> now email taking a step back in evolution towards non-MIME >>> mechanisms. Without ESMTP negotiation abilities that imply changes of >>> RFC2822 body content (but still intact content after MIME parsing). >>> >>> Please, spend some 10-20 seconds on this, and let me know what you >>> all think. >>> >>> paf >>> >>> On Nov 14, 2004, at 11:54, Patrik F?ltstr?m wrote: >>> >>>>> I'm afraid you lose me at step a): >>>>> >>>>> On Nov 11, 2004, at 8:03 PM, massanity-request at lists.paf.se wrote: >>>>> >>>>>> (a) I don't believe we will be able to have two ways of signing >>>>>> message bodies in the long run. Either we have multipart/signed, >>>>>> or sign the bucket of bits in the message (and ignore the MIME. >>>>>> We will never be able to have both >>>>> >>>>> This is not a belief that I share. There are *lots* of things we >>>>> have two ways of doing, why predict that this won't be another one? >>>> >>>> Because they technically are very very hard to implement at the >>>> same time. Sure, if we had two ways of doing the same thing that >>>> could coexist I would not be so nervous, but I don't think it is >>>> possible for these things. Just think of the transformations of >>>> the body of a message multipart/signed can create. Or what >>>> transformations 8BITMIME can create. >>>> >>>> I.e. all of our thinking in SMTP land since 1995 has been to >>>> protect the MIME structure and have the MIME structure not be >>>> damaged. Now with MASS initiatives, we once again are back to >>>> "don't change the bytes in the body". >>>> >>>> But, this is exactly what I want to discuss with you who know SMTP >>>> at least as well as I do (in many cases much much better). >>>> >>>>> More important, I don't think *either* of these two is the way >>>>> most of us have been looking at doing MASS signatures. I think >>>>> we're working on a third model here, one I would characterize for >>>>> lay audiences as a "low-resolution signature" (by analogy to >>>>> low-res graphics). Think of it not as a cryptographically signed >>>>> message, but a cryptographically signed *checksum* of the >>>>> message, using a checksum algorithm that is invariant across the >>>>> kinds of whitespace shifting and line wrapping that characterizes >>>>> email transport. >>>> >>>> Correct, there is a difference between the canonicalization of the >>>> message body itself, and what we pass to the hash function that >>>> calculates the signature. But, for example, is it correct to do >>>> this function so low-rez that it don't alarm when certain changes >>>> happen? I have seen ideas that for example strip 8th bit on bytes >>>> in the body, ignore what the has function "think" is a boundary >>>> between multipart messages (as the last boundary has '--' >>>> appended), and byte counters for how many bytes in the message is >>>> to be signed. Etc. >>>> >>>> The problem is that the checksum algorithm will be so low-rez, and >>>> still not work (due to added multipart-wrappers around existing >>>> messages, and changes in content-transfer-encoding during flight) >>>> that it will not fly. >>>> >>>> For example, I see too much of such issues with the Cisco idea, >>>> IIM. Every day there is a new "fun" problem. >>>> >>>>>> (b) If we sign the bucket of bits, we destroy the ability to use >>>>>> 8BIT content-transfer-encoding and the 8BITMIME ESMTP extension >>>>>> (that lead to encoding of messages during flight in some cases). >>>>> >>>>> This is the sort of issue we're still grappling with. My current >>>>> theory is that the "checksum" should be computed on a >>>>> canonicalized version of the message that undoes all transport >>>>> encodings and perhaps even ignores the purely syntactic elements >>>>> of the MIME structure (e.g. the boundary line) >>>> >>>> So, how are we supposed to handle the case where MTA's do add >>>> multipart/signature wrappers already today? That add a >>>> multipart/signature wrapper around the message as we have it today. >>>> Are we 100% sure the unwrapping will leave exactly the same number >>>> of bytes (and the same bytes) at the other end of the "tunnel"? >>>> >>>> I am so nervous we are optimizing either for old crap systems that >>>> can not handle MIME or for the new ones that do the right thing. >>>> That we can not do both, and that we will choose to optimize for >>>> the systems that are old and broken. >>>> >>>>> Does this help at all? -- Nathaniel >>>> >>>> Yes, it is exactly the correct direction to go with this discussion. >>>> >>>> paf >>>> >>> >>> _______________________________________________ >>> massanity mailing list >>> massanity at lists.paf.se >>> http://lists.paf.se/cgi/listinfo/massanity >> >> >> >> _______________________________________________ >> massanity mailing list >> massanity at lists.paf.se >> http://lists.paf.se/cgi/listinfo/massanity > > > > > > _______________________________________________ > massanity mailing list > massanity at lists.paf.se > http://lists.paf.se/cgi/listinfo/massanity From ned.freed at mrochek.com Sat Dec 18 16:09:08 2004 From: ned.freed at mrochek.com (ned.freed at mrochek.com) Date: Sat, 18 Dec 2004 07:09:08 -0800 (PST) Subject: [massanity] Re: Initial thoughts from Nathaniel In-Reply-To: "Your message dated Sat, 18 Dec 2004 07:51:45 +0100" <4821F57E-50C1-11D9-88A0-000A95B2B926@cisco.com> References: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> <8044E7F2-4F34-11D9-B805-000A95B2B926@cisco.com> <4821F57E-50C1-11D9-88A0-000A95B2B926@cisco.com> Message-ID: <01LIJAOG6SCQ00005R@mauve.mrochek.com> > I asked the people at Cisco working with the IIM proposal why they sign > the body of a message, and I got the answer "to protect against replay > attacks, where a signed message is grabbed, body changed, and then used > as spam". Further, even though it protects only the MX hop, they claim > the verification *can* be done end to end (verification in client) if > the MTA doesn't support MASS verification. Also, they explicitly want > the verification to survive what I would call two MX hops, where > mailing list explosion is happening in between the two hops. Simply put, they're completely delusional. As the recent discussion on the mailsig list has shown, the extent and variety of content transformations done to messages is *vast* and no signature scheme can possibly accomodate it. And this is the *rule*, not the exception, and the general trend is to do more of this sort of thing, not less. Lastly, o pretend that the IETF has any control over this, or any chance of stopping it or even slowing it down, is even more delusional. > So, what I see is (once again) that the list of "what problem are we > solving" is missing. Actually, I think the problem being solved in the abstract is pretty clear. What's missing is either an understanding of present-day email realities, a focus on practicalities rather than on the world-we-wish-we-had, or both. But you're right about this being "once again". We do this sort of thing all the time: We let the best be the enemy of the good. This is especially likely when security matters are involved. Like it or not, long-hop protection, despite its very real limitations, is the best we can hope for. We need to focus on that. If we don't the group is going to fail. I have made it known that I'm not going to waste time on yet another end to end signature scheme. Isn't four failures enough, for heaven's sake? (I'm sorry, but unlike Chris I don't count widespread implementation as a partial success. Widespread usage is what counts, and it hasn't happened.) Ned