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.