RE: SigComp Requirements (was Re: [rohc] RE: Default decompression algorithms)

> 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?

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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc