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

Mats Näslund <mats.naslund@era.ericsson.se> Tue, 01 July 2003 17:48 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 NAA08459 for <avt-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:20 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RIdGU16461 for avt-archive@odin.ietf.org; Fri, 27 Jun 2003 14:39:16 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vy7w-0004HO-0C; Fri, 27 Jun 2003 14:39:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19Vwnr-0002BB-6n for avt@optimus.ietf.org; Fri, 27 Jun 2003 13:14:27 -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 NAA07835 for <avt@ietf.org>; Fri, 27 Jun 2003 13:14:23 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vwnp-0004m2-00 for avt@ietf.org; Fri, 27 Jun 2003 13:14:25 -0400
Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47] helo=penguin.al.sw.ericsson.se) by ietf-mx with esmtp (Exim 4.12) id 19Vwne-0004kF-00 for avt@ietf.org; Fri, 27 Jun 2003 13:14:14 -0400
Received: from esealnt611.al.sw.ericsson.se (alteon-nat4.sw.ericsson.se [153.88.254.121]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5RH9Mw2024414; Fri, 27 Jun 2003 19:09:22 +0200 (MEST)
Received: from era.ericsson.se (eramoli_2k.er.ki.sw.ericsson.se [147.214.97.152]) by esealnt611.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id NW47W9HB; Fri, 27 Jun 2003 19:11:19 +0200
Message-ID: <3EFC7A44.8060808@era.ericsson.se>
Date: Fri, 27 Jun 2003 19:09:24 +0200
X-Sybari-Space: 00000000 00000000 00000000 00000000
From: Mats Näslund <mats.naslund@era.ericsson.se>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: David Mcgrew <mcgrew@cisco.com>
CC: Colin Perkins <csp@csperkins.org>, Allison Mankin <mankin@psg.com>, mbaugher@cisco.com, "Rolf Blom (EAB)" <rolf.blom@era.ericsson.se>, "Elisabetta Carrara (EAB)" <Elisabetta.Carrara@era.ericsson.se>, "Karl Norrman (EAB)" <Karl.Norrman@era.ericsson.se>, oran@cisco.com, avt@ietf.org
Subject: Re: Fwd: Re: [AVT] IESG Review of draft-ietf-srtp-08.txt - another set of comments
References: <4.3.2.7.2.20030627081442.01ecd5a0@mira-sjcm-1.cisco.com>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
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

Hi all,

David Mcgrew wrote:
> Mats, Colin, and others,
> 
> I belatedly realized that there is another advantage to using the RTP 
> padding over other schemes: compactness.  If someone implements CBC without 
> using the RTP padding, then the plaintext needs to be turned into a 
> prefix-free code so that the receiver can unambiguously remove any padding 
> that may be present.  Because of this, AES CBC ciphertext will expand by an 
> extra 16-octet block on messages for which no padding is needed, if the 
> conventional method is used (see Appendix A of 
> http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf for more 
> detail).  OTOH, if the RTP padding is used, then the padding bit indicates 
> the presence of padding, and there is never need to further expand the 
> ciphertext.  Also, the NIST document cited above makes it clear that any 
> suitable padding method is considered acceptable.   So this makes me think 
> that we should recommend RTP padding for use with modes that require padding.

Will someone concerned with compactness use a mode that requires
padding in the first place? Won't they rely on the pre-defined modes?

I honestly don't see how we can recommend a padding that we *know*
is "flawed", in particular when the flaw occurs in the absence
of integrity---something we had to fight allow at all!

I am fine with keeping the RTP padding as a sort of "default",
be honest about its pros and cons, but I would not go as far as
to *recommend* it.

> 
> As a side note, I would still prefer a CBC variant that doesn't use padding 

Agreed, but that is for a future extension of SRTP.

> as I'd mentioned before, but at any rate the compactness benefit of using 
> RTP padding deserves to be mentioned.

Absolutely, but so does the security problems.

/M


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