From paf at cisco.com Sun Nov 14 11:54:01 2004 From: paf at cisco.com (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Sun, 14 Nov 2004 11:54:01 +0100 Subject: [massanity] Initial thoughts from Nathaniel Message-ID: <7E943624-362B-11D9-924D-000A95B2B926@cisco.com> > 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 nsb at guppylake.com Sun Nov 14 18:12:50 2004 From: nsb at guppylake.com (Nathaniel Borenstein) Date: Sun, 14 Nov 2004 12:12:50 -0500 Subject: [massanity] The message Patrik replied to Message-ID: <69AC8CD6-3660-11D9-9FC8-000A9571873E@guppylake.com> I don't think my original message which Patrik replied to ever went through to the list, so here it is just in case: Begin forwarded message: From: Nathaniel Borenstein Date: November 12, 2004 11:49:49 AM EST To: massanity-request at lists.paf.se Subject: Re: Welcome to the "massanity" mailing list 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? 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. > (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) Does this help at all? -- Nathaniel -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2225 bytes Desc: not available URL: