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
- [AVT] IESG Review of draft-ietf-srtp-08.txt - ano… Allison Mankin
- Re: [AVT] IESG Review of draft-ietf-srtp-08.txt -… Colin Perkins
- Re: [AVT] IESG Review of draft-ietf-srtp-08.txt -… Mats Näslund
- Re: [AVT] IESG Review of draft-ietf-srtp-08.txt -… David Mcgrew
- Re: Fwd: Re: [AVT] IESG Review of draft-ietf-srtp… Mats Näslund
- Fwd: Re: [AVT] IESG Review of draft-ietf-srtp-08.… David Mcgrew
- [AVT] Re: IESG Review of draft-ietf-srtp-08.txt -… Mark Baugher