Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt

Qin Wu <sunseawq@huawei.com> Fri, 06 May 2011 01:42 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656AAE0754 for <avt@ietfa.amsl.com>; Thu, 5 May 2011 18:42:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.83
X-Spam-Level:
X-Spam-Status: No, score=-2.83 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9-CZhaH65B2 for <avt@ietfa.amsl.com>; Thu, 5 May 2011 18:42:14 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 60C1EE0688 for <avt@ietf.org>; Thu, 5 May 2011 18:42:14 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR008P53EAIR@szxga05-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:10 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LKR006L03E93H@szxga05-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:10 +0800 (CST)
Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LKR00M743E9CE@szxml04-in.huawei.com> for avt@ietf.org; Fri, 06 May 2011 09:42:09 +0800 (CST)
Date: Fri, 06 May 2011 09:45:41 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Message-id: <02b801cc0b8f$4f22c790$46298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset="iso-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <20110328090001.18465.38410.idtracker@localhost> <17CE6EA0-074D-43BD-990F-467F0A8708BD@vidyo.com> <001d01cc0b17$944dc5e0$46298a0a@china.huawei.com> <7D66AF27-F3CD-4E02-849B-DB2D12F60799@vidyo.com> <011e01cc0b8c$883392b0$46298a0a@china.huawei.com> <D85A85CA-DA8A-42E9-95FF-80E851321AED@vidyo.com>
Cc: avt@ietf.org
Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 May 2011 01:42:15 -0000

----- Original Message ----- 
From: "Jonathan Lennox" <jonathan@vidyo.com>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: <avt@ietf.org>
Sent: Friday, May 06, 2011 9:29 AM
Subject: Re: [AVTCORE] Fwd: I-D Action:draft-lennox-avtcore-srtp-encrypted-header-ext-00.txt


On May 5, 2011, at 9:25 PM, Qin Wu wrote:

> [Qin]: I agree using the same keystream to encrypt twice  will cause two-time pad security failure issue,
> i.e., first use the keystream to encrypt STRP payload, and then use the same keystream to encrypt 
> header extension elements.
> 
> However if we regard the payload of header extension elements and SRTP payload as a big payload, 
> we only need to use the same keystream to encrypt this big payload once. there is no two-time pad 
> security issue, right?

That's true, but it wouldn't be backward-compatible with existing receivers, which understand SRTP but ignore extension headers they're not familiar with -- the keystream would start in the wrong place.

[Qin]: So who will care header extension elements? the intermediary node or receiver who are signalled by SDP.
--
Jonathan Lennox
jonathan@vidyo.com