[AVTCORE] Writeup comments on draft-ietf-avtcore-aria-srtp-05

[Magnus Westerlund <[e-mail]>]

Authors, WG.

These are my comments on the ARIA draft found during my Write-up review.
These needs to be addressed prior to publication request can happen.

1. Section 6.2:
   [I-D.ietf-avtcore-srtp-aes-gcm]
              McGrew, D. and K. Igoe, "AES-GCM and AES-CCM Authenticated
              Encryption in Secure RTP (SRTP)", draft-ietf-avtcore-srtp-
              aes-gcm-10 (work in progress), September 2013.

Based on the formulations in the draft, this is a normative reference.
Please move it to the right section.



2. Section 5.2:

"IANA is requested to add the below crypto suite to the ..."

Replace "crypto suite" with "protection profiles"

3. Section 5.2:

"Note that these SRTP Protection Profiles do not specify an
   auth_function, auth_key_length, or auth_tag_length because all of
   these profiles use AEAD algorithms, and thus do not use a separate
   auth_function, auth_key, or auth_tag."

Not all of the above SRTP Protection Profiles are AEDA ones, thus I
suggest changing the above sentence to:

   Note that the majority of the SRTP Protection Profiles do not specify an
   auth_function, auth_key_length, or auth_tag_length because all of
   these profiles use AEAD algorithms, and thus do not use a separate
   auth_function, auth_key, or auth_tag.

4. Section 5.3:

   "In order to allow the use of the algorithms
   defined in this document in MIKEY, IANA is requested to add the below
   crypto suites to the "MIKEY Security Protocol Parameters SRTP Type 0
   (Encryption algorithm)" and to add the below PRF to the "MIKEY
   Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)"
   created by [RFC3830], at time of writing located on the following
   IANA page: http://www.iana.org/assignments/mikey-payloads/mikey-
   payloads.xml#mikey-payloads-26 [3]."

There is an issue with using "crypto suites" in the MIKEY context. What
you are registering are parameters for the ARIA SRTP transform, and then
you provide a mapping between the crypto suits to the transform
parameter's values.

Can we find another formulation here? Perhaps:

  "In order to allow the use of the algorithms
   defined in this document in MIKEY, IANA is requested to add three
encryption algorithms to the "MIKEY Security Protocol Parameters SRTP Type 0
   (Encryption algorithm)" and to add the below PRF to the "MIKEY
   Security Protocol Parameters SRTP Type 5 (Pseudo Random Function)"
   created by [RFC3830], at time of writing located on the following
   IANA page: http://www.iana.org/assignments/mikey-payloads/mikey-
   payloads.xml#mikey-payloads-26 [3]."

To further clarify the purpose of Figure 1 and 2 maybe one should modify
this text:

   MIKEY specifies the algorithm family separately from the key length
   (which is specified by the Session Encryption key length) and the
   authentication tag length.

To something like:

   MIKEY specifies the algorithm family separately from the key length
   (which is specified by the Session Encryption key length) and the
   authentication tag length. The SDP Security Descriptions [RFC4568]
   crypto suits and corresponding DTLS-SRTP [RFC5764] protection
   profiles are mapped to MIKEY parameter sets as shown below.


5. Abstract:
This document describes the use of the ARIA block cipher algorithm

I would change "describes" to "defines"

6. Section 2.2, and Section 2.3:
While Seciton 2.1 addresses Jonathan Lennox comments regarding defining
encryption key stream for Header Extensions the GCM and and CCM fails
to do this.

Although AES-GCM document do defines this in Section 9.3, I don't think
it is clear enough which cipher shall be used with ARIA. Thus add an
explicit definition also in these sections for how it is generated.

7. Section 2.1:
ARIA counter modes are
   defined in the same manner except that each invocation of AES is
   replaced by that of ARIA, and are denoted by ARIA_128_CTR,
   ARIA_192_CTR and ARIA_256_CTR respectively, according to the key
   lengths.

I am missing the normative reference to ARIA in the above sentence, is
this: RFC5794?

IF it is please include it here and the other places for the other modes
when you define the crypto as follows:
  this procedure but replace AES with ARIA [RFC5794]

Then also RFC5794 needs to be moved to the normative list.

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]
----------------------------------------------------------------------