[AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments

[Allison Mankin <[e-mail]>]

SRTP is on the agenda of the IESG again this week.
Some more comments on SRTP may still come in, but I thought
it would be worth sending on those of Russ Housley, the second Security
AD.  Steve Bellovin has supported the draft.  Russ has comments that 
seem straightforward to address.  Wait for more comments before 
sending in a revision, but so far things are going well.

Allison

> 
> >                     Yes    No-Objection  Discuss *  Abstain
> >
> >Russ Housley        [   ]     [   ]       [ X ]      [   ]
> 
> I have six comments.
> 
> 1.  In section 1, spell out the first use of RTCP.
> 
> 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.
> 
> 
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt