Subject: RE: SigComp Requirements (was Re: [rohc] RE: Default decompressio n algorithms)

From: "Price, Richard" <[email-masked]>
Date: Thu, 28 Feb 2002 16:06:53 -0000

> > I don't understand - what did I propose that contradicts the
> > current SigComp/UDVM draft?
> 
> UDVM uses state identifiers that uniquely identify state.
> In UDVM, there is no need for a central organization registering state
> identifiers.

For security reasons the UDVM always creates new state identifiers to be a
hash of the relevant item of state. However, when state is accessed the state
identifier is simply used as a key to retrieve the corresponding state. The
UDVM instruction for retrieving state doesn't check that the state identifier
is actually a hash of the state being retrieved - and why should it? Evaluating
the MD5 hash twice would throw away processing resources for no gain.

An implication of only evaluating the MD5 hash when the UDVM creates new
state is that if the state happens to be created externally, there is no need
for the state identifier to be a hash of the state at all. The collision
problem needs to be solved of course; having "a central organization
registering state identifiers" is one way to do this.

> > Nothing needs to be added to SigComp in order to support my proposal.
> 
> Not true, your new kind of state identifier has properties that differ from
> UDVM state identifiers. They are not adding capability.  Why bother?

As far as I can tell, the current SigComp draft does in fact allow my proposal
with no need for any modifications. Whether it *should* or not is another
matter entirely.

> I'd rather work on finishing the document.

Agreed. But since the current SigComp draft allows my proposal to be
implemented, we need to decide whether this is OK or not. Are there any
technical reasons for enforcing that application-defined state should always
be referenced by a hash?

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 28 Feb 2002 17:38:51 +0100

> technical reasons for enforcing that application-defined state

Not really.  We just have to add some text to the security considerations.
Currently a decompressor can rely*) that the state it references is correct,
as it actually hashes correctly (because there is no other way to create
it); with your addition, it can't.
*) Of course, if the UDVM is malicious, it can't, but then, this is
equivalent to the recipient system being malicious, and there is no way to
ensure packet integrity in this case, either.

What's wrong about hashes, btw?

We may want to restrict the size of the identifiers to a sensible range,
though (6 to 12, with 9 as the "general Internet" default).

To add some technical substance, here are some real work items (with
identifiers on them):

cabo-1) We need to decide what hash to use; people have pointed out that
SHA-1 may be a better choice than MD5.

cabo-2) We need to decide how to do the truncation -- I believe it should be
done uniformly (i.e., the identifier size should be a UDVM parameter); if
not, it should be possible to use different state identifier sizes to
reference the same state (substring match).

cabo-3) We need to add security analysis for the capability announcement
(hard!); again, I'd rather get rid of it by just setting values.

Gruesse, Carsten

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc