Re: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01

Magnus Westerlund <> Fri, 07 June 2013 14:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 02BF621F961B for <>; Fri, 7 Jun 2013 07:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kePhAblbSEkl for <>; Fri, 7 Jun 2013 07:20:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C94E221F9638 for <>; Fri, 7 Jun 2013 07:20:13 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-53-51b1ec1b88b2
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 6E.52.09795.B1CE1B15; Fri, 7 Jun 2013 16:20:12 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Fri, 7 Jun 2013 16:20:11 +0200
Message-ID: <>
Date: Fri, 07 Jun 2013 16:20:15 +0200
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Woo-Hwan Kim <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+Jvra7Mm42BBofXc1m87FnJbjF5soDF lt3nWByYPdb0JXssWfKTyePL5c9sAcxR3DZJiSVlwZnpefp2CdwZrRM/shd8U6349/oWewPj OrkuRk4OCQETic3LV7FD2GISF+6tZ+ti5OIQEjjFKPHw/hewhJDAMkaJe/PrQGxeAW2JxbOW MHUxcnCwCKhIfN1pChJmE7CQuPmjkQ3EFhUIljiyfTMLRLmgxMmZT8BsEQFViSdzGsFGMgvY Ssy+uJoZxBYWcJK43n6bEWSkkECAxJI2Z5Awp0CgxJc3v6BOk5TY8qIdqlVPYsrVFkYIW16i eetsZogrtSUamjpYJzAKzUKyeRaSlllIWhYwMq9iZM9NzMxJLzffxAgM3INbfhvsYNx0X+wQ ozQHi5I4rz7v4kAhgfTEktTs1NSC1KL4otKc1OJDjEwcnCCCS6qBcfHVxzvNRMJ1Lx7Z8CmJ 0c9xyqXwA3Eqt64llYiK3D7ocjXdXd72zcawNpMVt2a3/k3dM2m777b5vdmMV2wPnZjzIysl OSH3b6pjbor/kajNa18av3JuC9P+F+9v8IB/Vs6mtexcaZtDtr+0P1t6Iuo4+/fJ3WcZstVv m622cnBnjP+xUCjgrRJLcUaioRZzUXEiAO+V6fYvAgAA
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Jun 2013 14:20:35 -0000


Please see my replies inline.

On 2013-06-04 08:35, Woo-Hwan Kim wrote:
> First of all, we appreciate your helpful comment on the draft.
>>>2) Section 2.1 and 4:
>>>What are the security implications of using a 256 bit key length for the
>>>crypto but have as weak integrity protection as SAH1 32 bits? I think
>>>you need to discuss the implications of this, it doesn't appear to be
>>>particular balanced.
> We think that the key length and tag length should be treated separately.
> Though the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good, 
> the statement of Section 7.5 in RFC 3711 still seems to be valid for 192/256
> bit key block cipher.
> From another point of view, even when the tag length is short,
> large key length provides more security against key recovery attacks.
> So we would like to define ARIA ciphersuites corresponding to AES
> ciphersuites
> such as AES_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a 
> proper ciphersuite depending on environments.

Okay, I don't see any significant issue with that, but please be
explicit in the considerations that this combination is quite loop sided
from a security perspective.

>>>3) Section 2.2:
>>> The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
>>>   with SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>Looking in AES-GCM it appears to define a generic AEAD procedures for
>>>SRTP cipher suits. Can you please be more explicit and clear on how you
>>>use that generic procedure?
>>>4) Section 2.1, 2.2:
>>>These procedures are define by reference to existing algorithms like
>>>these sentences:
>>>    ARIA counter modes are
>>>   defined in a similar manner, and are denoted by ARIA_128_CTR,
>>>   ARIA_192_CTR and ARIA_256_CTR respectively, according to the key
>>>   lengths.  The plaintext inputs to the block cipher are formed as in
>>>   AES-CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs
>>>   are processed as in AES-CTR.
>>>   The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>   of AES-GCM and AES-CCM with SRTP.  The use of ARIA-CCM and ARIA-GCM
>>>   with SRTP is defined the same as that of AES-CCM and AES-GCM.
>>>I think using words as "similar" and not being very explicit about what
>>>procedures from the other specification that applies here provide some
>>>risk for misunderstanding. I hope you can be more explicit and clear on
>>>which procedures and usage are applicable.
> The only difference between ARIA ciphersuites and AES ciphersuites is 
> whether to invoke ARIA or AES. There is no difference in modes of
> operation itself. 
> Thus we think it is not necessary to define AEAD procedures and other
> modes of 
> operations more explicitly in the draft if there are proper references.
> If the word "similar" is inappropriate, we'll replace it by the word
> "same". 
> The below sentences can be added.
> - ARIA counter modes are defined in the same manner except that each
> invocation of 
> AES is replaced by that of ARIA.
> - The use of ARIA-CCM and ARIA-GCM with SRTP is defined the same as 
> that of AES-CCM and AES-GCM except that each invocation of AES is replaced
> by ARIA.

Correct, I agree with reference procedures when they exist. But you need
to be explicit about this. Same is better, but I haven't judged if that
makes it obvious how you apply ARIA instead of AES.

> We are following the AES-SRTP documents including
> draft-ietf-avtcore-srtp-aes-gcm.
> Section 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is
> used for CCM and
> it is written that the tag size for GCM is determined by the algorithm
> choice.
> But the tag size for CCM also can be determined by the algorithm choice and 
> it is better to define CCM ciphersuites for each tag size. We submitted
> such opinion,
> but not accepted yet.

Okay, if that discussion is from the AES-GCM last call, I think you need
to re-raise this on the list as a focused email on that issue. I don't
seem to be able to find any reply to those comments. So please remind
the authors about this issue and lets see if we can come to a conclusion
on it.


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: