[AVTCORE] Observation in RFC 3711

[Christian Oien <[e-mail]>]

Hello WG,

After reading RFC 3711, and making an implementation in the context of RFC
4568 for the default ciphers, and then, afterwards, looking at a couple of
existing implementations, I have come to the conclusion of having found
a mismatch between the specification and the existing implementations,
including libsrtp.

RFC 3711 section "4.3 Key Derivation" describes a formal operator DIV,
with a result having the same number of bits as its first operand.
For SRTP the first operand is the SRTP packet index, which is a 48-bit
quantity, meaning that the <label> will have 48 bits to its right XOR'ing
with master_salt.

In subsection "4.3.2 SRTCP Key Derivation" the text says "Replace the
SRTP index by the 32-bit quantity" which means that the DIV operator will
yield a 32-bit quantity.  Following the specification of key_id for SRTCP
the <label> will have 32 bits to its right when XOR'int with master_salt.

The implementations, including libsrtp, invokes this XOR with the
<label> at the same position as for SRTP.  According to the specification
this should be done 16 bits to the right of this, when invoking for SRTCP.

It seems to me that the most pragmatic thing to do is to update the
specification, not the implementations.  But any new implementer
will fail to exchange any SRTCP with software using e.g. libsrtp.
This prevents any i.e. PLI of being communicated.  The consensus of not
following the specification, has the same implication for [ DTLS ] as for
security-description key-derivation input, namely that all SRTCP session
material is non-compliant and thus implementers reading the specification
instead of a reference-implementation, will fail.

In support of making an errarta for update of RFC 3711 is that
the specifications way of doing this has, according to itself, has a
cryptographic weakness, related to the rationale of having the <label>.
I am not sure about the implications of this weakness, but it seems like
support for *not* following specification as its current text strictly
instructs via its DIV operator and the 32-bit quantity :  Re-keying
(non-zero key_derivation_rate as opposed to RFC 4568 ciphers) with
SRTP packet index 196608 gives identical encryption key as for SRTCP,
in the case that e.g. none of the latter has yet been sent (index zero).
The implication of any key-stream re-use was the reason of having <label>.

  - Christian S Oien