[AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-05

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 18 April 2013 15:09 UTC

Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4E21F8F6D for <avt@ietfa.amsl.com>; Thu, 18 Apr 2013 08:09:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.12
X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id HjpvkFSggIGf for <avt@ietfa.amsl.com>; Thu, 18 Apr 2013 08:09:48 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id 95D2F21F8F69 for <avt@ietf.org>; Thu, 18 Apr 2013 08:09:47 -0700 (PDT)
X-AuditID: c1b4fb30-b7f266d000000cb5-8e-51700cba53e9
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain []) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.09.03253.ABC00715; Thu, 18 Apr 2013 17:09:46 +0200 (CEST)
Received: from [] ( by esessmw0237.eemea.ericsson.se ( with Microsoft SMTP Server id; Thu, 18 Apr 2013 17:09:45 +0200
Message-ID: <51700CB9.4030601@ericsson.com>
Date: Thu, 18 Apr 2013 17:09:45 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: IETF AVTCore WG <avt@ietf.org>, "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" <draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+Jvre4unoJAg8UXpC1e9qxkt1h7JNGB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyni5uIupYJFqxYe2CYwNjDtkuxg5OCQETCTW bYrtYuQEMsUkLtxbz9bFyMUhJHCKUeLO09msEM5yRokFq1+ygFTxCmhLbH/fzQZiswioSuy+ cYEZxGYTsJC4+aORDWSoqECwxNbWGIhyQYmTM5+wgMwREehglLhxYT07SEJYwFyib9YvJojN khJbXrSDxZkF9CSmXG1hhLDlJZq3zgabLwS0t6Gpg3UCI/8sJHNnIWmZhaRlASPzKkb23MTM nPRy802MwAA7uOW3wQ7GTffFDjFKc7AoifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cB4SGftoVd7fXa9v7TzA+fywxPM1aNb/z45tHs5Q8jxqkOt3jbabjvZVkaEvfl6ciXTUlHN ZCOLirtzxYRy1Ax/LsvoTL76yUy2u275s70zTvr+OWvoW2ZiXO/4KuNWA/vKA3n3J3oX7Z4x YWf2jbaDd+K3aq2IEEw1PaDN7rP0ZnGU9YMPzGLTlViKMxINtZiLihMBb81yyP4BAAA=
Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-05
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: Thu, 18 Apr 2013 15:09:49 -0000

Authors and WG,

In my review of the draft in preparing the Document Shepherd's writeup I
found some issues that I believe needs to be fixed.

1) Section 14.1:
Security description [RFC 4568] defines SRTP "crypto suites"; a
   crypto suite corresponds to a particular AEAD algorithm in SRTP.

As the registry is located on the SDP page it can be difficult to find
and it also not named as written I propose to change this to:

Security description [RFC 4568] defines the "SRTP Crypto Suite
Registrations" registry on the "Session Description Protocol (SDP)
Security Descriptions" page currently located at
   crypto suite corresponds to a particular AEAD algorithm in SRTP.

2) Security Descriptions and the "inline" value string
Section of RFC 4568 says:

  The semantics of the SRTP crypto suite MUST be described in an RFC in
   accordance with the RFC 2434 Standards Action, including the
   semantics of the "inline" key-method and any special semantics of

As there is no such definition of how the inline method is actually
using the fields for these algorithms this drafts appears to not be in

Please look at RFC 4568 to figure out what is missing. I think at
minimum one needs to define if one has both key and salt and how many
octets that is going to be. Pointers to the DTLS SRTPprotection profiles
is likely part of the solution here.

3) Section 14.2:

DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile";

This registry is actually named "DTLS-SRTP Protection Profiles" on
IANA's page.

4) IANA registry:

   On the SRTP policy Type/Value list (derived from Table 6.10.1.a of
   [RFC3830]) we request the following addition:

      Type | Meaning                         | Possible values
       TBD | AEAD authentication tag length  | 8, 12, or 16 (in octets)

This registry is called :

MIKEY Security Protocol Parameters at

Can you please confirm that it is this registry you want to add to?

5) IANA registry:

14.4. AEAD registry

   We request that IANA make the following additions to the AEAD

                 AEAD_AES_128_CCM_12     = TBD
                 AEAD_AES_256_CCM_12     = TBD

You are not using the exact correct names for the registry:

Would indicate that you should write this as:

 We request that IANA make the following additions to the IANA
Authenticated Encryption with Associated Data (AEAD) Parameters page's
registry for "AEAD Algorithms":

6) Abstract:

   This document defines how AES-GCM and AES-CCM Authenticated
   Encryption with Associated Data algorithms can be used to provide
   confidentiality and data authentication in the SRTP protocol.

The ID-Checklist says:
Should be meaningful to someone not versed in the technology; most
abbreviations must be expanded on first use.

This makes me wonder if you should expand the acronyms, although they
probably need to be present in the acronym form to enable searching for

7) Usage of RFC 2119 words

8.1. SRTP/SRTCP Authentication Field

   The AEAD message authentication mechanism MUST be the primary message
   authentication mechanism for AEAD SRTP/SRTCP.  Additional SRTP/SRTCP
   authentication mechanisms SHOULD NOT be used with any AEAD algorithm
   and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED
   and SHOULD NOT be present.

"NOT RECOMMENDED" is not included in the normal blurb text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      "OPTIONAL" in this document are to be interpreted as described in
      RFC 2119.

So please modify it to include "NOT RECOMMENDED" as it is actually
defined as part of the RFC.

I also sent some basic editorial issues to the authors directly. Some
which was unresolved isssue found by ID-Nits, please use it before
submitting the draft!


Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVM
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com