[massanity] Re: Initial thoughts from Nathaniel

Sat Dec 18 07:51:45 CET 2004

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