[secdir] secdir review of draft-kanno-tls-camellia

Sandra Murphy <Sandra.Murphy@sparta.com> Tue, 12 April 2011 16:42 UTC

Return-Path: <Sandra.Murphy@cobham.com>
X-Original-To: secdir@ietfc.amsl.com
Delivered-To: secdir@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9858FE0835; Tue, 12 Apr 2011 09:42:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSRSN9vVd5wl; Tue, 12 Apr 2011 09:42:25 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfc.amsl.com (Postfix) with ESMTP id C3E51E072E; Tue, 12 Apr 2011 09:42:25 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id p3CGgOuS032685; Tue, 12 Apr 2011 11:42:24 -0500
Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id p3CGgO2t023897; Tue, 12 Apr 2011 11:42:25 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([65.38.193.21]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Apr 2011 12:42:24 -0400
Date: Tue, 12 Apr 2011 12:42:24 -0400
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: secdir@ietf.org, draft-kanno-tls-camellia@tools.ietf.org
Message-ID: <Pine.WNT.4.64.1104121206030.5412@SMURPHY-LT.columbia.ads.sparta.com>
X-X-Sender: sandy@mailbin.sparta.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-OriginalArrivalTime: 12 Apr 2011 16:42:24.0759 (UTC) FILETIME=[99FF6870:01CBF930]
Cc: iesg@ietf.org
Subject: [secdir] secdir review of draft-kanno-tls-camellia
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <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: Tue, 12 Apr 2011 16:42:26 -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.


This document adds new cipher suites to TLS that include the use of the 
Camilla algorithm.

The document follows the format of other documents that have defined 
cipher suites to TLS.  In most cases the text just points to those other 
documents.

It is entirely possible that with sufficient time to study the 9 or 10 
references that point to the definition of other cipher suites being cited 
as models for these cipher suites, I'd be able to view the document as 
obvious.  Unfortunately I had neither the experience nor the time for 
sufficient study.  So I found the text not clear about what other cipher 
suites were being invoked as models for the suites here.

The security consideration section points to the sections in seven other 
similar documents.  I have not been able to review that list of security 
considerations sections to see that they adequately cover the concers for 
this algorithm. But as this document is not proposing any novel new 
combinations of security features and (according to the document, not me) 
Camilla is very similar to AES, I presume that security considerations are 
adequately covered.  I know of no security concerns specific to Camilla.

The language in section 3 (cipher suite definitions) makes frequent 
mention of the way similar suites are defined elsewhere.  As a person who 
is not au courant on cipher suites, I did not find the language obvious.

    Advanced Encryption Standard (AES) [20] authenticated encryption with
    additional data algorithms, AEAD_AES_128_GCM and AEAD_AES_256_GCM are
    described in RFC5116 [8].  And AES GCM cipher suites for TLS are
    described in RFC5288 [10].  AES and Camellia share common
    characteristics including key sizes and block length.
    CAMELLIA_128_GCM and CAMELLIA_256_GCM are defined according as those
    of AES.

I believe that the authors mean that the definitions of the Cammilla 
suites are the same as in section 5.1 and 5.2 of 5116 and section 3 of 
5288, with appropriate substitution of "Camilla" for "AES", but I am not 
sure which of the cipher suites in 2.1, 2.2 and 2.3 of this document are 
included.  Particularly as the PSK suites listed in 2.3 would seem to be 
described in section 3.4 with reference to entirely other documents.
Perhaps someone more experienced with cipher suites would think this was 
obvious, but I could have used a more explicit mapping between the suites 
defined here and the suites from which the descriptions are being 
borrowed.

Section 3.4 is particularly opaque to my inexperienced eyes as to the 
mapping between these cipher suites and the similar cipher suites whose 
descriptiosn are being borrowed:

    PSK cipher suites for TLS are described in RFC4279 [5], RFC4785 [7],
    RFC5487 [12], and RFC5489 [13].

That is the complete description of the suites.

Which ref applies to which suite in this document?

--Sandy