2. I find the structure of section 2 confusing. I had to read it twice to
understand it. I think that a second level of indenting would be one way
to fix it. I am sure there are others.
3. In section 3.1, in the paragraph after figure 1, please delete:
"It is exact for the pre-defined transforms."
This point is made more clearly later in the paragraph. Then, at the end
of the same paragraph, the document says:
"While it could seem more attractive to specify a fixed padding
scheme for all transforms, security and flexibility of transform
specifications REQUIRE that each transform specify a secure
padding method."
I disagree. IPsec and S/MIME both specify padding schemes that are
employed by all of the ciphers. Please reword. Do not use "REQUIRE" in
the replacement.
4. In section 3.2.1, the document says: "the master key(s), which MUST be
random and kept secret." This is quite a high bar. I suggest that
pseudo-random is sufficient. Please see the RFC 2828 definitions of
"random" and "pseudo-random." The document says that it is following these
terms. Also, see RFC 1750. Similarly, the requirement on the master salt
should also be reduced to pseudo-random.
5. The last paragraph is section 3.2.3 says:
"If no valid context can be found for a packet corresponding to a
certain context identifier, that packet MUST be discarded from
further SRTP processing."
Elsewhere, "discarded from further processing" is used. This seems better
to me. It is discarded, which seems different that no further SRTP
processing. Also, SRTCP should be covered by this statement.
6. In section 4.1.1, I am confused by the term "fixed key" in the following:
"For a fixed Counter Mode key, each IV value used as an input MUST be
distinct, in order to avoid the security exposure of a two-time pad
situation (Section 9.1). To satisfy this constraint, an
implementation MUST ensure that the values of the SRTP packet index
of ROC || SEQ, and the SSRC used in the construction of the IV are
distinct for any fixed key. The failure to ensure this uniqueness
could be catastrophic for Secure RTP. This is in contrast to the
situation for RTP itself, which may be able to tolerate such
failures. It is RECOMMENDED that, if a dedicated security module is
present, the RTP sequence numbers and SSRC either be generated or
checked by that module (i.e., sequence-number and SSRC processing in
an SRTP system needs to be protected as well as the key). "
I think that "fixed" means "any particular key" but I am not sure.