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

Satoru Kanno <> Wed, 15 June 2011 13:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A57A11E810E; Wed, 15 Jun 2011 06:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fegnEiZp4fst; Wed, 15 Jun 2011 06:01:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A613611E80F0; Wed, 15 Jun 2011 06:01:17 -0700 (PDT)
Received: from (sadoku33 []) by (8.14.4/8.13.4/NTTSOFT) with ESMTP id p5FD18PO028041; Wed, 15 Jun 2011 22:01:08 +0900 (JST)
Received: (from root@localhost) by (8.13.8/NTTSOFT) id p5FD183m017038; Wed, 15 Jun 2011 22:01:08 +0900 (JST)
Received: from [] by with SMTP id YAA17037; Wed, 15 Jun 2011 22:01:08 +0900
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p5FD17Nm021847; Wed, 15 Jun 2011 22:01:07 +0900
Received: from (localhost []) by (8.14.4/NTTSOFT) with ESMTP id p5FD17Li025093; Wed, 15 Jun 2011 22:01:07 +0900 (JST)
Received: from ccmds32 ( []) by (8.14.4/NTTSOFT) with SMTP id p5FD17Fh025090; Wed, 15 Jun 2011 22:01:07 +0900 (JST)
Message-ID: <>
Date: Wed, 15 Jun 2011 22:00:55 +0900
From: Satoru Kanno <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Sandra Murphy <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
X-Mailman-Approved-At: Wed, 15 Jun 2011 08:04:40 -0700
Subject: Re: [secdir] secdir review of draft-kanno-tls-camellia
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Jun 2011 13:01:27 -0000

Hi Sandra,

Thank you for your comments.
And I'm sorry for delayed response. Because I was missing your email.

At First, this draft is almost same document structure on RFC6209 (i.e., 
ARIA for TLS).

We reconsidered and revised three parts (3.2 Cipher, 3.4 PSK cipher 
suites, and 4. Security Considerations).
The details are follows;

o 3.2 Cipher
I wrote additional information to supplement in this section.
Because this section is not clear on kinds of modes, I wrote additional 
paragraph as follows;

    This document describes cipher suites based on Camellia cipher using
    CBC mode and GCM.  The details are follows;

o 3.4 PSK cipher suites
I mainly reviewed references and mapping between RFC and cipher suite.

For references, I removed RFC4279 (only cipher suites based on SHA-1) 
and RFC4785 (only NULL encryption) from this section, because we did not 
define these cipher suites in our draft.

For mapping between RFC and cipher suite
I wrote additional information to supplement for RFCs.

    PSK cipher suites for TLS are described in RFC5487 [11] as to SHA-
    256/384 and RFC5489 [12] as to ECDHE_PSK.

o 4. Security Considerations
I reviewed and reconsidered on references of section.
I removed RFC4279 (including RFC5487), RFC4785 (not defined in NULL 
encryption), RFC5288 (including RFC5487), and GCM (including RFC5116) 
from this section.

    The security considerations in previous RFCs (RFC5116 [7], RFC5289
    [10], and RFC5487 [11]) apply to this document as well.

I updated next draft (-03) including some editorial corrections.
Please check this draft.


(2011/04/13 1:42), Sandra Murphy wrote:
> 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

Satoru Kanno

Security Business Unit
Mobile and Security Solution Business Group
NTT Software Corporation

TEL: +81 45 212 9803       FAX: +81 45 212 9800