Re: [Hipsec] Proposed new list for HIP_TRANSFORM

Robert Moskowitz <rgm@htt-consult.com> Thu, 07 January 2010 03:27 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D36AD28C0FD for <hipsec@core3.amsl.com>; Wed, 6 Jan 2010 19:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 IDDmyKI0Mf6h for <hipsec@core3.amsl.com>; Wed, 6 Jan 2010 19:27:19 -0800 (PST)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id E789028C131 for <hipsec@ietf.org>; Wed, 6 Jan 2010 19:27:18 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 40A7D68B84; Thu, 7 Jan 2010 04:24:54 +0000 (UTC)
X-Virus-Scanned: amavisd-new at localhost
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMO7gJlxoXzX; Wed, 6 Jan 2010 23:24:45 -0500 (EST)
Received: from nc2400.htt-consult.com (unknown [IPv6:2607:f4b8:3:1:21b:77ff:fe43:978]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 5F20B68B86; Wed, 6 Jan 2010 23:24:45 -0500 (EST)
Message-ID: <4B455483.4070404@htt-consult.com>
Date: Wed, 06 Jan 2010 22:26:59 -0500
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Thunderbird/3.0
MIME-Version: 1.0
To: Andrew McGregor <andrew@indranet.co.nz>
References: <4B440CA5.3010209@htt-consult.com> <4B44C35E.8090200@hiit.fi> <4B44CA15.2070905@htt-consult.com> <4B44D016.7050102@hiit.fi> <CE2F5651-0202-4D6F-B357-CFD49ABF0815@indranet.co.nz>
In-Reply-To: <CE2F5651-0202-4D6F-B357-CFD49ABF0815@indranet.co.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP <hipsec@ietf.org>
Subject: Re: [Hipsec] Proposed new list for HIP_TRANSFORM
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2010 03:27:20 -0000

On 01/06/2010 10:22 PM, Andrew McGregor wrote:
> On 07/01/2010, at 7:01 AM, Miika Komu wrote:
>
>    
>> Robert Moskowitz wrote:
>>
>> Hi,
>>
>>      
>>> On 01/06/2010 12:07 PM, Miika Komu wrote:
>>>        
>>>> Robert Moskowitz wrote:
>>>>
>>>> Hi,
>>>>
>>>>          
>>>>> Proposed new list for HIP_TRANSFORM:
>>>>>
>>>>>          Suite ID                          Value
>>>>>
>>>>>          RESERVED                          0
>>>>>          AES-CBC with HMAC-SHA1            1     ([RFC3602], [RFC2404])
>>>>>          3DES-CBC with HMAC-SHA1           2     ([RFC2451], [RFC2404])
>>>>>          DEPRECATED                        3
>>>>>          BLOWFISH-CBC with HMAC-SHA1       4     ([RFC2451], [RFC2404])
>>>>>          NULL-ENCRYPT with HMAC-SHA1       5     ([RFC2410], [RFC2404])
>>>>>          DEPRECATED                        6
>>>>>          NULL-ENCRYPT with HMAC-SHA2       7     ([RFC2410], [RFC4868])
>>>>>          AES-CBC with HMAC-SHA2            8     ([RFC3602], [RFC4868])
>>>>>          AES-CCM-8                         9     [RFC4309]
>>>>>          AES-CCM-12                        10    [RFC4309]
>>>>>          AES-CCM-16                        11    [RFC4309]
>>>>>          AES-GCM with a 8 octet ICV        12    [RFC4106]
>>>>>          AES-GCM with a 12 octet ICV       13    [RFC4106]
>>>>>          AES-GCM with a 16 octet ICV       14    [RFC4106]
>>>>>            
>>>> seems fine with me. Should the "natural" key size be reflected in some of the algorithms descriptions?
>>>>          
>>> I am not sure what you are alluding to here.  Key sizes for AES-based transforms start at 128 and go up.  If you are asking about those 8/12/16 sizes in CCM and GCM, that applies to the auth size.
>>>        
>> do we have to negotiate AES key size?
>>      
> No!  We need more suite IDs for the key sizes we're going to use.
>    

I thank Paul and Andrew for jumping in and giving some good feedback.

So 128 and 256?  Skip 192?

> The whole point of using suites in the first place was, once you have the suite you know everything you need to know about the crypto setup... you can literally just use the suite-id as an index into a table of all the numbers.
>
> Andrew
>