Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt

Jonathan Lennox <> Tue, 07 June 2011 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7567711E81D6 for <>; Tue, 7 Jun 2011 09:41:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YxJFyUJyGZDv for <>; Tue, 7 Jun 2011 09:41:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A292611E81D5 for <>; Tue, 7 Jun 2011 09:41:35 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 0327E554577 for <>; Tue, 7 Jun 2011 12:41:35 -0400 (EDT)
X-Virus-Scanned: by SpamTitan at mail.lan
Received: from HUB025.mail.lan (unknown []) by (Postfix) with ESMTP id 7FA06553669 for <>; Tue, 7 Jun 2011 12:40:17 -0400 (EDT)
Received: from BE235.mail.lan ([]) by HUB025.mail.lan ([]) with mapi; Tue, 7 Jun 2011 12:39:04 -0400
From: Jonathan Lennox <>
To: "" <>
Date: Tue, 07 Jun 2011 12:40:16 -0400
Thread-Topic: New Version Notification for draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt
Thread-Index: AcwlMZRXouhvRM62TbSL5uJJaxcjqA==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 Jun 2011 16:41:36 -0000

Hi, all --

The header extension encryption draft is now published as a WG document.

There are no technical changes from the final individual submission, but I wanted to call people's attention to two issues I've introduced discussion about in this version of the draft.

1.  We've seen additional discussion on the list recently (in the context of the Suite B work) about the draft defining AES-GCM for SRTP.  I'm not terribly familiar with AES-GCM, so it's not clear to me how its encryption transforms (or other AEAD transforms) should apply to the encrypted header extension mechanism.

Since both encrypted header extensions and AES-GCM SRTP are AVTCORE working group items, I think it's important that we understand how these pieces fit together.  I'd need guidance from someone who understands AES-GCM better.

2.  The two-byte form of header extensions (with "defined by profile" field 0x100x) allows zero-length header extension elements, and also can use the low four bits of the "defined by profile" field as an extra extension field.  The mechanism in this draft doesn't provide protection for either of these cases.  I don't think this is a problem -- in either case, switching to a one-byte header extension element that carries the relevant information is perfectly possible, and would also allow transport over the 0xBEDE one-byte form of header extensions -- but I wanted to get working group consensus that this is okay.

Comments on other aspects of the draft are also welcome, of course. 

On Jun 7, 2011, at 4:44 AM, <> wrote:

> A new version of I-D, draft-ietf-avtcore-srtp-encrypted-header-ext-00.txt has been successfully submitted by Jonathan Lennox and posted to the IETF repository.
> Filename:	 draft-ietf-avtcore-srtp-encrypted-header-ext
> Revision:	 00
> Title:		 Encryption of Header Extensions in the Secure Real-Time Transport Protocol (SRTP)
> Creation date:	 2011-06-01
> WG ID:		 avtcore
> Number of pages: 9
> Abstract:
>   The Secure Real-Time Transport Protocol (SRTP) provides
>   authentication, but not encryption, of the headers of Real-Time
>   Transport Protocol (RTP) packets.  However, RTP header extensions may
>   carry sensitive information for which participants in multimedia
>   sessions want confidentiality.  This document provides a mechanism,
>   extending the mechanisms of SRTP, to selectively encrypt RTP header
>   extensions in SRTP.
> The IETF Secretariat

Jonathan Lennox