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 ----------------------------------------------------------------------
- [AVTCORE] Comments on draft-ietf-avtcore-aria-srt… Magnus Westerlund
- Re: [AVTCORE] Comments on draft-ietf-avtcore-aria… Woo-Hwan Kim
- Re: [AVTCORE] Comments on draft-ietf-avtcore-aria… Magnus Westerlund
- [AVTCORE] Re: Comments on draft-ietf-avtcore-aria… Woo-Hwan Kim