On Fri, 9 Nov 2001, Dale Moberg wrote: In my earlier long message I tried to summarize: 1. what kind of threats might be provided 2. under what transport/packaging conditions given the typical processing of 3. ebXML messages. I considered a number of possible kinds of threats. Apparently Jim thinks it is only the threat of misdirection that should be of concern. So, Well, no, not at all. I understand that you might think that if you were reading only my last message. My last message was reacting to what I perceived to be a common thread in all of your prior message, that is, all threats that are detected by what is being proposed can be reduced to denial of service. Since we offer no protection for denial of service and accept that there is very little, if anything, we could do even if we wanted, let's not do what it is being proposed. for that threat, these considerations still stand: 1. ebXML messaging processing does not need to trust internal MIME content-type values. If this is true then the specification needs to address this as part of its integration of security services. To do this it needs to make explicit that MIME packaging is just that, packaging, and all other information (except the Content-ID) needs to be ignored from the point of view of ebXML. To further emphasize this point then all MIME content-type headers should be set to application/octet-stream , since the MSH will know the correct type from the manifest. If you don't do this then some implementation will no doubt use some information from the MIME headers. As soon as it does this -- and you have to assume it will be done in a risk analysis -- you have created a vulnerability. It is my opinion this vulnerability is easily protected and, in fact, it should be. 2. content-id values, if changed, will almost certainly lead to an error condition when they are used as part of XMLDsig signatures. I'm not yet convinced of this as I haven't yet worked through the all the scenarios of re-ordering body parts and mixing and matching Content-ID: headers with payloads. 3. CPA based agreements can be used to: a. check that internal mime content-types are as expected. MIME error can be thrown if enforced. b. add digital enveloping that can encrypt the entire MIME chunk, including the headers (using 1847 security packaging if you like, Jim!) It concerns me when you want to use CPA-based agreements to solve the problems. It bothers me because it suggests we don't really know the answer and let's make it someone else's problem. In any case you have just now stated that MIME headers are important, since the CPA is going to check/use them. This should mean they need to be protected, right? Given all of this existing apparatus permitting strong counters for the situation of MITM header tweaking, if you still wish to mandate an additional new security mechanism, I urged you to hold off until the next iteration. By then, maybe XMLEncryption will be stable or other security proposals may have emerged that can be cited. Maybe a tweak to the mid: or cid: URIs that would permit mid: sub-segments-- who knows? ebXML messaging is IMO not primarily engaged in inventing new security solutions and countermeasures, but instead is involved in adopting existing stable solutions to achieve an acceptable coverage for the standard threats (spoofing, alteration, and sniffing). I would rather retrofit to a dedicated security groups carefully examined spec. than try to throw something together at the last minute (and we are at the last minute for 1.1). I'm sorry but I can not support this position. With more than 10 years of experience with IETF Security Standards one thing I've learned is you can not retrofit security. My concern is that security is hard enough to get right without having to figure out how to make it right with a protocol that wasn't designed to be secure in the first place. I agree we have a lot of tools available to us but there are issues with respect to how those tools are used to achieve a desired goal and to ensure interoperability. That is my only real point. We need to make sure we have it right and now is the time to do it. I'm sorry that I am coming in to this rather late in the game. I'm not trying to make this difficult or cause a significant delay, but I do think this issue is important. Jim