+1 !
Chris
Dale Moberg wrote:
> This summary concerns whether we should be spending a lot
> of time worrying about how to protect internal MIME content-*
> headers for the purposes of ebXML messaging.
>
> Jim Galvin remarked that:
>
> "Regardless of where the MIME headers are duplicated -- whether the
> manifest or in the signature element as an object -- the point is it
> needs to be required, not optional."
>
> And Rich Salz's aside that:
>
> I deliberately didn't specify WHICH headers to encode, it's up to the
> sender to determine which ones to protect. The spec should advise, of
> course.
>
> (By the way, for what it's worth, I don't think this defense will be
> necessary in real pratice.)
> /r$
>
> I would like to support, and possibly extend,
> Rich Salz's position that
> while there may be a MITM threat posed by unprotected
> MIME content-* headers, it is not a threat
> that greatly impacts ebXML messaging.
> There might be a minor threat of
> denial of service (but this is a threat
> that signing headers will not alleviate).
> The remedies adopted should not be made
> REQUIRED as urged by Jim Galvin. I also
> think it is actually of marginal utility
> to even get involved
> in protecting the internal bodypart headers.
>
>
> Here are supporting reasons (many already mentioned):
>
> 1. (Internal) Header modification is most
> commonly a problem for one transport,
> SMTP, when using Relays (or Gateways or other intermediaries).
> "Helpful" CTE changes and companion header changes
> are presumably not going to happen
> under HTTP or HTTPS, even when intermediaries are involved,
> unless they gateway into email. And simply ignore any
> BEEP profile that has the problem :-) So a "MITM threat"
> based on changed headers is usually not malicious, and not
> universal across transports. In a way, the SMTP situation speaks
> for not including headers in the scope of the signature
> if we are mainly concerned with the threat of inadvertently
> breaking signatures that are otherwise good. In other words,
> by including headers in the scope of the signature, we
> risk not getting the payload (potentially validly signed
> and intact) processed, because a signature check would fail
> due to the changed headers in the SMTP relay case.
> We are opening ourselves up to uninintentional
> denial of service by signing headers!
> If headers were important, and they were in danger
> of being maliciously changed,
> then using a Suresh/RichSalz method could
> be optionally adopted (but I think simplicity would
> favor not going there).
>
> As Chris Ferris mentioned, peer to peer transports using
> transport layer encryption would frustrate header manipulation.
> Likewise, digital envelopes would discourage header manipulation,
> even when intermediaries (gateways, relays, MSHes,
> various FW proxies,etc) are involved.
> This means there exist other ways of avoiding the MITM
> threat to headers when it is thought to be a live possibility.
> This means that mandating some redundant encoding of
> headers is not universally warranted; whether it is even
> a live possibility, depends on the specifics of transport
> as well as packaging. No reason to require unconditionally.
>
> 2. There could be hijacked relays or even other
> hijacked intermediaries and they could
> change headers maliciously. One suggested change
> was to alter the content-type header so that the payload
> processing would benefit the hijacker somehow,
> by misdirecting it to another application handler.
>
> However, the _routing_ function within ebXML has largely dispensed
> with any strict dependence on the semantics of MIME content-*
> fields. MIME is mainly being used for its generalized bundling
> and unbundling capability. The diminished dependence on the
> MIME apparatus is partly because whatever the service or action
> element says, the ebXML payload will
> most likely just have the same old content-type of "text/xml" or
> "application/xml" ( or maybe "*/*+xml.") Why did we have service
> and action elements, if we were going to use the MIME apparatus for
> application-level routing? The MIME values were
> regarded as insufficiently fine-grained.
> The MIME content-type provides a partly
> redundant, insufficiently informative label, that within
> ebXML messaging, can be largely ignored for app. routing
> purposes anyway. So, MITM threat largely irrelevant for internal
> content-type headers and the application level misrouting.
> No reason to require unconditionally.
>
> 3. MITM change of headers could at least interfere
> with processing, and so be an interference with
> service attack. If the goal is interfering with service,
> however, there are a lot of other attacks that would
> be easier/faster/cheaper to undertake.
> Signing headers would not in itself defeat
> the interference with service, but just offer another
> way to detect it. Signing provides no remedy for this
> threat. No reason to require here.
>
> 4. Another possible reason to show
> that the "message" had not been messed with,
> would be to discourage a certain
> kind of "replay" ( payload recycling ).
> By binding a SOAP envelope
> to its payload(s) by signing,
> we would at least have some evidence about
> the entity that was replaying the payload.
> (It would not prevent it, of course. We could
> always still cut and paste an independently
> signed payload and repack, resign, resend.)
>
> Interestingly, we already decided that some changes
> are "don't care" with respect to
> message "integrity" (the changes intermediaries
> do to the SOAP envelope, for example).
> Given this existing agreement--which forced our use
> of XMLDsig in the first place--why not just
> decide to exclude the headers from within
> the scope of the signature,
> and say that ebXML message "integrity"
> does not guarantee that the bodypart headers
> have not changed (added, deleted,
> changed case, been given wrong values, etc)?
>
> As Suresh pointed out, the one bodypart header
> that ebXML messagers do care about a little
> (content-id) is one whose alteration will
> most probably throw
> an exception during processing anyway,
> if we are using XMLDsig. Since the
> error is already detected, no reason
> to require internal header signing here
> either.
>
> None of the other headers
> (content-description, -disposition,etc)
> supply info that needs to be trusted in the typical
> ebXML messaging case. If the payload
> did happen to be some elaborate MIME
> structure of many varied content types
> with embedded multiparts and whatnot,
> protecting all these headers could get
> quite complex. Easier to just envelope 'em
> if there is a viable threat of MITM.
> Mandating some header protection scheme
> again unwarranted.
>
> 5. Under a CPA, the packaging elements would specify
> what the content types and layout are supposed
> to be for a specific conversation. The
> wrong content-type headers could be detected and
> warned about. So, again, embedding and
> signing a header is not universally warranted
> or necesary.
>
> All that said, if you still want to complicate
> things by worrying about a threat with very
> little real disutility, the Suresh/RichSalz procedure
> seems OK as an optional 2.0 addition. I think
> there is yet no compelling reason to require its
> use unconditionally within ebXML messaging, however.
>