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

[Magnus Westerlund <[e-mail]>]

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
"http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml";
a
   crypto suite corresponds to a particular AEAD algorithm in SRTP.


2) Security Descriptions and the "inline" value string
Section 10.3.2.1 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
   parameters.

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
conformance.

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
http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml

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
   registry:

                 AEAD_AES_128_CCM_12     = TBD
                 AEAD_AES_256_CCM_12     = TBD


You are not using the exact correct names for the registry:
http://www.iana.org/assignments/aead-parameters/aead-parameters.xml

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
them.

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
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
      "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!


Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------