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

Woo-Hwan Kim <whkim5@ensec.re.kr> Tue, 04 June 2013 07:32 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 E39E421E8136 for <avt@ietfa.amsl.com>; Tue, 4 Jun 2013 00:32:23 -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 Wh5QDyzg3zg1 for <avt@ietfa.amsl.com>; Tue, 4 Jun 2013 00:32:13 -0700 (PDT)
Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7B421F9BB4 for <avt@ietf.org>; Mon, 3 Jun 2013 23:35:02 -0700 (PDT)
Received: by mail-we0-f177.google.com with SMTP id m19so1638776wev.22 for <avt@ietf.org>; Mon, 03 Jun 2013 23:35:01 -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=iSKPKOOwVOCAlx3mYOLzG+4zYYv1RGWR9I5BV+RgT9U=; b=AwLc0UhrtjIvN1plt99qD6o0YQCi93dJLVOdtBQn5gYlSKyCrk1Oa6vjoh/8j84kcg p4nmcqujfJXZvYVBrecquqU8IwiTUOo3EOOGsXSvy8f/PU15Mo/0oC/VU7x+m5n0mf/x 4Ti2xy3bKUYWMY5DlOPyAP9MJN5Hx+XaHVmCvbbXC25BVt2ny3EnFV+pjavUwT+1gGLm sDEnypWrnbmn2NYEXK7+4TQVAcdsAisVdyynWXSlzOvto50KOfK+hx/jbMhxNXvBywgS gSBYxvi7VBD5ffXZ67kek4SYn05Vp7ywtOS0DkXI+SvzKzjDC+GhOcQbGnElAvKeKk/y QKpQ==
MIME-Version: 1.0
X-Received: by 10.180.14.130 with SMTP id p2mr565087wic.32.1370327701713; Mon, 03 Jun 2013 23:35:01 -0700 (PDT)
Sender: woohwankim@gmail.com
Received: by 10.216.192.133 with HTTP; Mon, 3 Jun 2013 23:35:01 -0700 (PDT)
Date: Tue, 04 Jun 2013 15:35:01 +0900
X-Google-Sender-Auth: EawDv0bh_3-oQVD8O6oVsgO8GHU
Message-ID: <CAMRi9CfzzLHW8wLo=o6jow-7680mJprTe+S34Ljxu-WhKikg5A@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="f46d040f9f44e2f6c304de4e471a"
Cc: draft-ietf-avtcore-aria-srtp@tools.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: Tue, 04 Jun 2013 07:32:24 -0000

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.

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

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.

For other comments ((1), (5) ~ 10)), I'll revise the old draft to reflect
your comment.
We'll update the draft soon.

Sincerely,
Woo-Hwan Kim