[AVTCORE] Re: Comments on draft-ietf-avtcore-aria-srtp-01
Woo-Hwan Kim <whkim5@ensec.re.kr> Thu, 27 June 2013 05:14 UTC
Return-Path: <woohwankim@gmail.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 49E4921F9BD3 for <avt@ietfa.amsl.com>; 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 <avt@ietfa.amsl.com>; 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 <avt@ietf.org>; Wed, 26 Jun 2013 22:13:50 -0700 (PDT)
Received: by mail-wi0-f179.google.com with SMTP id hj3so207893wib.0 for <avt@ietf.org>; 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: <CAMRi9CdjmsT7weuqySjvGyjiR7AuOUha633W7cAaBe-6=OTidQ@mail.gmail.com>
From: Woo-Hwan Kim <whkim5@ensec.re.kr>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, 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 <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: Thu, 27 Jun 2013 05:14:00 -0000
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 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