Re: [secdir] Security review of draft-ietf-avtcore-aria-srtp-09

Ben Campbell <ben@nostrum.com> Fri, 07 July 2017 20:19 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3785126C3D; Fri, 7 Jul 2017 13:19:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjcCmEKpC2sc; Fri, 7 Jul 2017 13:19:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CE8124217; Fri, 7 Jul 2017 13:19:51 -0700 (PDT)
Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v67KJi5U068863 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 7 Jul 2017 15:19:48 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <000701d2f5ec$3a25d2d0$ae717870$@nsr.re.kr>
Date: Fri, 07 Jul 2017 15:19:43 -0500
Cc: Ben Laurie <benl@google.com>, The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-avtcore-aria-srtp.all@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1045AA0-D786-499E-8B31-0B489850B837@nostrum.com>
References: <CABrd9STW9g5_uct50Vf=KR_6VhkXgCiwFL66yZdYOR7p78Rvsg@mail.gmail.com> <000701d2f5ec$3a25d2d0$ae717870$@nsr.re.kr>
To: Woo-Hwan Kim <whkim5@nsr.re.kr>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/jiGah247vWqK-b0IdRNEQfPgQhM>
Subject: Re: [secdir] Security review of draft-ietf-avtcore-aria-srtp-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Jul 2017 20:19:54 -0000

> On Jul 5, 2017, at 7:10 PM, Woo-Hwan Kim <whkim5@nsr.re.kr> wrote:
> 
> Sorry for our late reply and thank you for your comments.
> 
>>> I have reviewed this document as part of the security directorate's ongoing effort to review >>all IETF documents being processed by the IESG.  These comments were written primarily for >>the benefit of the security area directors.  Document editors and WG chairs should treat >>these comments just like any other last call comments.
>>> 
>>> The summary of the review is ready with nits.
>>> 
>>> This is essentially a drop-in replacement of AES for SRTP with ARIA, a cipher I've never >>heard of.
>>> 
>>> Because it is a drop-in replacement, it uses SHA-1. Probably it would be better practice to >>update the hash function to something more modern.
> 
> We agree. But we think that such updates should be based on the revision of the standard RFC (including RFC 3711). So it may be not possible in this stage.

Given that a main point of this draft is to register current usage, I agree. But would it make sense to add a paragraph to the security considerations pointing out the use of SHA1 and mentioning what needs to happen to evolve the specs to support newer hash functions? (or even hash agility).
> 
>>> The I-D also somewhat eccentrically says that no security problems have been found with ARIA >>whilst referencing a paper on a meet-in-the-middle attack on reduced round ARIA. I am not >>sure what to make of this, though clearly it is not a fatal flaw.
> 
> The reason for referencing the paper [TSL] is that the results of the security analysis on ARIA up to the time when first draft was proposed are summarized in the paper. We wanted that the reference paper is accepted as an evidence of the security of ARIA. Considering the problem you pointed out, however, it seems to be failed to clearly express our intension. So we revised the draft by adding the sentence “Previous security analysis results are summarized in [ATY]”. In addition, we replaced the reference [TSL] by the new reference [ATY] because the results of the security analysis on ARIA have been published to date. This new reference also contains a summary of almost all results of security analysis on ARIA up to date.
> 
> Thanks again for your review, and we've posted a revision(-10) that reflects your feedback.
> 
> Sincerely, Woo-Hwan Kim
>