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