[secdir] SECDIR review of draft-ietf-avt-seed-srtp-11

canetti <canetti@post.tau.ac.il> Wed, 03 June 2009 10:18 UTC

Return-Path: <secdir-bounces@mit.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D04413A67A3 for <secdir@core3.amsl.com>; Wed, 3 Jun 2009 03:18:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyEWeG6z-cof for <secdir@core3.amsl.com>; Wed, 3 Jun 2009 03:18:52 -0700 (PDT)
Received: from pch.mit.edu (PCH.MIT.EDU [18.7.21.90]) by core3.amsl.com (Postfix) with ESMTP id E5C373A6A55 for <secdir@ietf.org>; Wed, 3 Jun 2009 03:18:40 -0700 (PDT)
Received: from pch.mit.edu (pch.mit.edu [127.0.0.1]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53AIgJt026245 for <secdir@ietf.org>; Wed, 3 Jun 2009 06:18:42 -0400
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id n53AIdsw026219 for <secdir@PCH.mit.edu>; Wed, 3 Jun 2009 06:18:39 -0400
Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id n53AIU26027298 for <secdir@mit.edu>; Wed, 3 Jun 2009 06:18:31 -0400 (EDT)
Received: from doar.tau.ac.il (localhost [127.0.0.1]) by mit.edu (Spam Firewall) with ESMTP id 92D951EA2838 for <secdir@mit.edu>; Wed, 3 Jun 2009 06:18:30 -0400 (EDT)
Received: from doar.tau.ac.il (gate.tau.ac.il [132.66.16.26]) by mit.edu with ESMTP id dVYb4CSymzcVqxR8 for <secdir@mit.edu>; Wed, 03 Jun 2009 06:18:30 -0400 (EDT)
Received-SPF: pass (mit.edu: domain of canetti@post.tau.ac.il designates 132.66.16.26 as permitted sender) receiver=mit.edu; client_ip=132.66.16.26; envelope-from=canetti@post.tau.ac.il;
Received: from [10.0.0.5] (unknown [193.37.128.224]) by doar.tau.ac.il (Postfix) with ESMTP id 58F32BEF8; Wed, 3 Jun 2009 13:18:28 +0300 (IDT)
Message-ID: <4A264DE7.6080407@post.tau.ac.il>
Date: Wed, 03 Jun 2009 13:18:15 +0300
From: canetti <canetti@post.tau.ac.il>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: secdir@mit.edu, cfrg@ietf.org, avt@ietf.org, seokung@kisa.or.kr
X-Scanned-By: MIMEDefang 2.42
X-BeenThere: secdir@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: secdir-bounces@mit.edu
Errors-To: secdir-bounces@mit.edu
Subject: [secdir] SECDIR review of draft-ietf-avt-seed-srtp-11
X-BeenThere: secdir@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Wed, 03 Jun 2009 10:18:54 -0000

***   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 draft describes the use of the SEED cipher (RFC 4269) within the SRTP 
protocol. The document is well written and thorough. I see no problems with it.

My only potential concern is regarding the use of SEED itself. SEED is a 
cipher that's apparently very popular in Korea and less so elsewhere. While 
no weaknesses have been found afaik, it did not receive the level of 
scrutiny that AES did.  Thus, the question arises whether the IETF should 
standardize (and thereby implicitly endorse) the use of this cipher as an 
alternative to AES.

I personally see no problem here, as long as a security comparison is made 
clear in the document. Still, others may feel differently.
In fact, for this purpose I cc'ed the cfrg RG on this evaluation.


Best,
Ran



_______________________________________________
secdir mailing list
secdir@mit.edu
https://mailman.mit.edu/mailman/listinfo/secdir