On Wed, 2004-12-01 at 20:58, Jim Fenton wrote:
Douglas Otis wrote:
Rather than waging a battle over how robust a signature should be, by
allowing a message-state header that describes the message content to
detect what has been damaged could easily serve two very legitimate
purposes. One being the detection as to what is being damaged within
the message, the other would be to allow a more discerning means for
rejecting a message on the basis of a signature failure. Let the market
decide how this gets used.
Something like- (see: rfc2822 & rfc2045/6/7)
H0 := "RECEIVED"
H1 := "MESSAGE-ID"
[etc.]
As compared with copying the headers, the only advantage I see here is
that this trace header is shorter. Is that advantage worth the effort
and complexity of defining a new language (that would need to be
extended as new headers get invented, I suppose)?
I showed an example of using a header that was not already defined
within a header dictionary. It is a simple way to obtain header
compression. I already do this as a matter of course when correlating
message statistics. With a modest amount of effort, a better dictionary
can be created for more complete coverage and is really simple code.
Also, if a message signature fails and it turns out that one of the
headers has changed, that's still not enough information to know that
there hasn't also been a cut & paste attack on the body. In fact, it
seems like one could substitute anything, and then provide a MSTATE
header that makes everything but one of the header fields look good, and
the recipient is likely to think that just that one header has changed.
The MSTATE header is part of the message signature. There can be no
simple fiddling within this content. I would be happy to provide CRC
code for this instead. ; )
In other words, this has diagnostic value but does not provide a more
discerning means for rejecting a message. Or am I missing something?
The MSTATE header information provides two things. It tells you the
original length as well as a simple hash value of the header or data
section. Analysis could make simple guesses as to the original
information, and confirm this with the simple hash. Once the header or
message part has been restored or removed, the signature is rechecked.
This process only succeeds when the signature validates.
As long as the mung process does not discard information that can not be
guessed, then a copy is not needed. If you apply this over the entire
message, then any change can be detected and identified. This is not a
property when just using a signature. This is similar to the older
strategy in storage of just using cyclic checks versus today's strategy
of using error correction. By adding additional checks, the strength of
the system is improved. Your disk drive hides error corrections from
you, but it is always happening...
-Doug