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

Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 07 June 2013 14:20 UTC

Return-Path: <prvs=5870ac8b49=magnus.westerlund@ericsson.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BF621F961B for <avt@ietfa.amsl.com>; Fri, 7 Jun 2013 07:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.249
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kePhAblbSEkl for <avt@ietfa.amsl.com>; Fri, 7 Jun 2013 07:20:28 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id C94E221F9638 for <avt@ietf.org>; Fri, 7 Jun 2013 07:20:13 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-53-51b1ec1b88b2
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6E.52.09795.B1CE1B15; Fri, 7 Jun 2013 16:20:12 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 7 Jun 2013 16:20:11 +0200
Message-ID: <51B1EC1F.6050200@ericsson.com>
Date: Fri, 07 Jun 2013 16:20:15 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
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 <whkim5@ensec.re.kr>
References: <CAMRi9CfzzLHW8wLo=o6jow-7680mJprTe+S34Ljxu-WhKikg5A@mail.gmail.com>
In-Reply-To: <CAMRi9CfzzLHW8wLo=o6jow-7680mJprTe+S34Ljxu-WhKikg5A@mail.gmail.com>
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
Cc: draft-ietf-avtcore-aria-srtp@tools.ietf.org, avt@ietf.org
Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-aria-srtp-01
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: Fri, 07 Jun 2013 14:20:35 -0000

Hi,

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.

Cheers

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