[massanity] Re: Initial thoughts from Nathaniel

[James M Galvin]

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 
<paf at cisco.com> 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