[massanity] Re: Initial thoughts from Nathaniel

[Chris Newman]

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
> <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
> 
> 
> 
> _______________________________________________
> massanity mailing list
> massanity at lists.paf.se
> http://lists.paf.se/cgi/listinfo/massanity