Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)

Magnus Westerlund <> Thu, 29 January 2015 11:02 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E92A21A01F6; Thu, 29 Jan 2015 03:02:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Cd2VrkUHdkQ; Thu, 29 Jan 2015 03:02:56 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 147121A00CD; Thu, 29 Jan 2015 03:02:55 -0800 (PST)
X-AuditID: c1b4fb25-f791c6d00000617b-39-54ca135e4345
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6C.04.24955.E531AC45; Thu, 29 Jan 2015 12:02:54 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 29 Jan 2015 12:02:53 +0100
Message-ID: <>
Date: Thu, 29 Jan 2015 12:02:53 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: David McGrew <>, Stephen Farrell <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyM+JvjW6c8KkQg78HJS1e9qxkt1j57Tqr xdojiRYz/kxktphw6jWrxdVVf9gtpu+9xu7A7jHl90ZWj7XdV9k8liz5yeTRv+slq8eXy5/Z AlijuGxSUnMyy1KL9O0SuDLa9k1mLPgiXjG7cwdLA+M24S5GTg4JAROJtlWTmSBsMYkL99az dTFycQgJHGGUODF9CTuEs5xRYvmO5WwgVbwC2hLvTs9iBLFZBFQlNmxsAetmE7CQuPmjEaxG VCBYYvHzp6wQ9YISJ2c+YQGxRQSCJFbu+AUWZxboZJLY058OYgsLxEnMermJHcQWEvjEJHHp vxWIzSlgK/HvzEw2iHoDiSOL5kD1yks0b53NDFGvLdHQ1ME6gVFwFpJ1s5C0zELSsoCReRWj aHFqcVJuupGxXmpRZnJxcX6eXl5qySZGYPgf3PJbdQfj5TeOhxgFOBiVeHgNFp0MEWJNLCuu zD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDY4aE21KX11Wma7QXyU7u 7f/iUxzX/u/as+a4z79yjvrMmSt8PWTzrpg/N/ftuL+pw7epwkjghEdhZPPUKVW3buzQm9DR WbjgnbTFuiUW4e33XRgC3vJcz1605FTYdu22kt/H0zl9cmcxJ4RJLTy2xmI9g8GGEo27voof azq46gNtLlfc2ds7V4mlOCPRUIu5qDgRAEpsII1gAgAA
Archived-At: <>
Cc: "" <>, "" <>, The IESG <>, IETF AVTCore WG <>
Subject: Re: [AVTCORE] Stephen Farrell's Discuss on draft-ietf-avtcore-srtp-aes-gcm-14: (with DISCUSS)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jan 2015 11:02:59 -0000

Hi Stephen, All,

(Adding the AVTCORE WG): WG there are feedback requested from you below!

I am taking over as shepherd for this document and would like to make
some progress here.

I would like to make some observations around the discuss.

First, that Stephen appear to grouping AES-GCM and AES-CCM into one
bucket. From my perspective they are defined as two different ciphers
for SRTP but within a single document. One can implement either of them
without any requirement on implementing the other from this document.

Each of them have MTI requirements on configurations that MUST be
supported if one support that particular cipher. That is defined as
strongest for each key length.

>From the draft:

Section 13.1:

   Any implementation of AES-GCM SRTP MUST support both AEAD_AES_128_GCM
   and AEAD_AES_256_GCM (the versions with 16 octet AEAD authentication
   tags), and it MAY support the four other variants shown in table 1.

Section 13.2:

   Any implementation of AES-CCM SRTP/SRTCP MUST support both
   AEAD_AES_128_CCM and AEAD_AES_256_CCM (the versions with 16 octet
   AEAD authentication tags), and MAY support the other four variants.

I would further also note that to make anything MTI for SRTP independent
on deployment and usage, then a document must Update the MTI definition
in RFC 3711, something that hasn't been done yet. So far it is up to the
umbrella specifications, like WebRTC etc as discussed in SRTP not
mandatory document (RFC 7202) to define what ciphers that MUST be
implemented. And if we are updating RFC 3711 the mandatory to implement
for any SRTP implementation will certainly be a question.

When it comes to the core of your discuss if these 4 (AES-GCM) + 6
(AES-CCM) options must be defined. That is difficult question. One which
is difficult to answer within the context of the WG actually. As David
has raised in the private discussion so far there will be people that
will argue anything other than the longest tags and keys are acceptable,
others will note that using the 16 byte authentication tags do results
in the authentication data being more than the RTP payload (single audio
frame) for a number of the audio formats we have. Me personally I think
I would remove the 12 bytes tag-length from AES-CCM to reduce the number
of options. But two tag-lengths and two key-lengths do not appear

WG, the chairs and ADs appreciate feedback on your view here.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: