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

Colin Perkins <csp@csperkins.org> Mon, 23 June 2003 22:37 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13871 for <avt-archive@odin.ietf.org>; Mon, 23 Jun 2003 18:37:29 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5NMb4D27879 for avt-archive@odin.ietf.org; Mon, 23 Jun 2003 18:37:04 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZvp-0007ED-OG; Mon, 23 Jun 2003 18:37:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19UZul-0007D8-Jq for avt@optimus.ietf.org; Mon, 23 Jun 2003 18:36:10 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13834 for <avt@ietf.org>; Mon, 23 Jun 2003 18:35:51 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19UZui-0006ES-00 for avt@ietf.org; Mon, 23 Jun 2003 18:35:52 -0400
Received: from wireless206.east.isi.edu ([65.123.202.206] helo=purple.nge.isi.edu) by ietf-mx with esmtp (Exim 4.12) id 19UZuX-0006EC-00 for avt@ietf.org; Mon, 23 Jun 2003 18:35:41 -0400
Received: from purple.nge.isi.edu (localhost [127.0.0.1]) by purple.nge.isi.edu (8.12.9/8.12.9) with SMTP id h5NMYvFp034520; Mon, 23 Jun 2003 18:35:03 -0400 (EDT) (envelope-from csp@csperkins.org)
Date: Mon, 23 Jun 2003 18:34:57 -0400
From: Colin Perkins <csp@csperkins.org>
To: Allison Mankin <mankin@psg.com>
Cc: mats.naslund@era.ericsson.se, mbaugher@cisco.com, rolf.blom@era.ericsson.se, Elisabetta.Carrara@era.ericsson.se, mcgrew@cisco.com, Karl.Norrman@era.ericsson.se, oran@cisco.com, avt@ietf.org
Subject: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments
Message-Id: <20030623183457.0534f0a4.csp@csperkins.org>
In-Reply-To: <E19UYci-0007Ic-Cs@psg.com>
References: <E19UYci-0007Ic-Cs@psg.com>
Organization: http://csperkins.org/
X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i386-unknown-freebsd4.8)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit

[inline]

--> Allison Mankin <mankin@psg.com> writes:
> 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.

If IPsec and S/MIME both define a standard padding mechanism, why cannot
SRTP do the same?  And, perhaps, use the standard RTP padding mechanism?

-- 
Colin Perkins
csp@csperkins.org

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt