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

[Jonathan Lennox <[e-mail]>]

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, <[e-mail]> 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
[e-mail]