Return-Path: 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 49E4921F9BD3 for ; Wed, 26 Jun 2013 22:14:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 1IlmJLoE0Wcs for ; Wed, 26 Jun 2013 22:13:59 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB4921F92E3 for ; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id hj3so207893wib.0 for ; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=LxOKEFf6Ms9KEPaknLMJEuLx1JG9KoVm4jyYZ9s7ZVs=; b=xkSFitzMYV3SL/cc0L/u0PGmpbkfXREddoKS5zZWEYDuvMjaFH6LbyzGidUIMiZ3rW hQAeejF8OCUw8tzpoCgyUB5k0BKBZAZnFggJdRInJMu9RS/f7UVdLMquIUZaZaKbrZCh F3l0qXK9H+INhk7IaS6LGL7+9jeDOj3oIgd3VZYYQ59z91Lc3Zp4HsFZRKZmiu/akjrv U4UF6FZbQ3pwwnbLWg/scOajjol5fvJSi4SVKEmOFdyPO023AAx/hQsM5TsQG/RxpSs6 jlXbKb5wiwh/TNQLdjFQmIQLdtUGlhoHFbFhl472ZLrXqEwkWLq4beW36jyIPWcR3ajb Y4ug== MIME-Version: 1.0 X-Received: by 10.194.123.69 with SMTP id ly5mr5009262wjb.29.1372310030248; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.216.161.133 with HTTP; Wed, 26 Jun 2013 22:13:50 -0700 (PDT) Date: Thu, 27 Jun 2013 14:13:50 +0900 X-Google-Sender-Auth: iFjDvtvg919qvP7PyNuWb-qQ4uU Message-ID: From: Woo-Hwan Kim To: Magnus Westerlund , avt@ietf.org Content-Type: multipart/alternative; boundary=089e01175f83dff17b04e01bd316 Cc: draft-ietf-avtcore-aria-srtp@tools.ietf.org Subject: [AVTCORE] Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:14:00 -0000 --089e01175f83dff17b04e01bd316 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We'll add some comments regarding the risk of short tags in the security considerations of new version(-03) and post a mail about AES-CCM ciphersuites issues. Thanks. Best Regards, Woo-Hwan Kim > 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 th= e >>>>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=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > --089e01175f83dff17b04e01bd316 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We'll add some comments regarding the risk of short ta= gs in the security considerations of new version(-03)
and post a mail a= bout AES-CCM ciphersuites issues.

Thanks.

Best Regards, Woo-Hwan Kim

> Hi,
>
> Please see= my replies inline.
>
>
> On 2013-06-04 08:35, Woo-Hwan K= im 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<= /span>
>>>>particular= balanced.
>>=
>> We think that the key l= ength and tag length should be treated separately.
>> Though= the security balance of ARIA-192/256 and HMAC-SHA1_32 is not good,<= br style=3D"font-family:arial,sans-serif;font-size:14px">>> the statement of Section= 7.5 in RFC 3711 still seems to be valid for 192/256
>> bit ke= y block cipher.
>> F= rom 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 A= RIA ciphersuites corresponding to AES
>> cipher= suites
>> such as AE= S_192/256_CM_HMAC_SHA1_32 (RFC 6188), and let users can choose a
>> proper= ciphersuite depending on environments.
>
> Okay, I do= n't see any significant issue with that, but please be
> explicit in the considerations that = this combination is quite loop sided
> from a sec= urity perspective.
>
>>=
>>>>3) Section 2.2:<= /span>
>>>>= ;
>>>> The int= ernet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use
>>>>= ; =A0 of AES-GCM and AES-CCM with SRTP. =A0The use of ARIA-CCM and ARIA-GCM=
>>>> =A0 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 g= eneric procedure?
>>>>= ;
>>>><= br style=3D"font-family:arial,sans-serif;font-size:14px"> >>>>= ;4) Section 2.1, 2.2:
>= >>>
>>>>= ;These procedures are define by reference to existing algorithms like
>>>>these sentences= :
>>>>= ;
>>>> =A0 =A0= ARIA counter modes are
>>>>= ; =A0 defined in a similar manner, and are denoted by ARIA_128_CTR,<= br style=3D"font-family:arial,sans-serif;font-size:14px">>>>> =A0 ARIA_192_CTR= and ARIA_256_CTR respectively, according to the key
>>>>= ; =A0 lengths. =A0The plaintext inputs to the block cipher are formed as in=
>>>> =A0 AES-= CTR(AES_CM, AES_192_CM, AES_256_CM) and the block cipher outputs
>>>>= ; =A0 are processed as in AES-CTR.
>>>>
>>>>= ; =A0 The internet draft[I-D.ietf-avtcore-srtp-aes-gcm] describes the use >>>>= ; =A0 of AES-GCM and AES-CCM with SRTP. =A0The use of ARIA-CCM and ARIA-GCM=
>>>> =A0 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 misu= nderstanding. I hope you can be more explicit and clear on
>>>>= ;which procedures and usage are applicable.
>>
>> The on= ly difference between ARIA ciphersuites and AES ciphersuites is
>> whether to invoke ARIA or AE= S. There is no difference in modes of
>> operat= ion itself.
>> Thus = we think it is not necessary to define AEAD procedures and other
>> modes = of
>> operations mor= e explicitly in the draft if there are proper references.
>>=
>> If the word "simil= ar" is inappropriate, we'll replace it by the word
>> "= same".
>> The b= elow sentences can be added.
>>=
>> - ARIA counter modes ar= e defined in the same manner except that each
>> invoca= tion of
>> AES is re= placed 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 ex= cept that each invocation of AES is replaced
>> by ARI= A.
>
> Correct, I= agree with reference procedures when they exist. But you need
> to be explicit about this. Same i= s better, but I haven't judged if that
> makes it o= bvious how you apply ARIA instead of AES.
>
>>=
>> We are following the AE= S-SRTP documents including
>> draft-= ietf-avtcore-srtp-aes-gcm.
>> Sectio= n 5.2 in the draft-ietf-avtcore-srtp-aes-gcm, Tag_Size_Flag is
>> used f= or CCM and
= >> it is = written that the tag size for GCM is determined by the algorithm
>> choice= .
>> But the tag siz= e 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 no= t accepted yet.
>
> Okay, if t= hat 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 let= s see if we can come to a conclusion
> on it.
>
> Cheers
>
> Magnus Wes= terlund
>
> ----------= ------------------------------------------------------------
> Multimedia= Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------<= /span>
> Ericsson A= B =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 = Stockholm, Sweden| mailto:=A0magnus.wes= terlund@ericsson.com
> ----------= ------------------------------------------------------------
>
=
--089e01175f83dff17b04e01bd316--