[AVT] Re: IESG Review of draft-ietf-srtp-08.txt - another set ofcomments

[Mark Baugher <mbaugher@cisco.com>]

Allison,
   We have addressed five out of the six comments from Russ at 
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-09.txt.  The 
document is available with highlighted changes at 
http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-avt-srtp-09.pdf.  There 
have been some small editorial changes made as well and we paired down the 
authors list from seven authors to five to be in accordance with IETF 
policy.  Rolf Blom and Dave Oran asked that their names be removed to 
comply with the policy.  They played an important role in starting the SRTP 
effort and in guiding it and we thank them for that.

  I said that we addressed five out of six comments.  We could not agree 
on what if anything needed to be changed in Section 2 (Russ's item #2) and 
decided to leave it as it is.

  We'll submit this version to internet-drafts as well.

Mark
At 02:13 PM 6/23/2003 -0700, Allison Mankin wrote:
> 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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt