Re: about security level evaluation of draft-zhou-6man-mhash-cga-00

Jari Arkko <jari.arkko@piuha.net> Tue, 27 March 2012 14:21 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED61F21F88AC for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level:
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5YJAkzIkajd for <ipv6@ietfa.amsl.com>; Tue, 27 Mar 2012 07:21:55 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id 413D921F88AB for <ipv6@ietf.org>; Tue, 27 Mar 2012 07:21:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1C7FC2D35A; Tue, 27 Mar 2012 17:21:54 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZNEiMvVCTPM; Tue, 27 Mar 2012 17:21:52 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 748B42CC56; Tue, 27 Mar 2012 17:21:52 +0300 (EEST)
Message-ID: <4F71CD00.8000208@piuha.net>
Date: Tue, 27 Mar 2012 16:21:52 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: zhou.sujing@zte.com.cn
Subject: Re: about security level evaluation of draft-zhou-6man-mhash-cga-00
References: <OF974F286A.B19B0ED5-ONC12579CE.004B58ED-C12579CE.004C335D@zte.com.cn>
In-Reply-To: <OF974F286A.B19B0ED5-ONC12579CE.004B58ED-C12579CE.004C335D@zte.com.cn>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "ipv6@ietf.org" <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 14:21:57 -0000

Well, I think it is quite a simple trade-off. Increasing Sec increases computational effort on both sides by equal amount. Increasing the length of the hash increases computational effort only on the attacker side. As a result, the hash bits are relatively valuable.

The trade-off that we have in front of us is to choose between:

1) Status quo: RFC 4982 eats three bits for Sec, leaving 59 bits of hash length after accommodating for u and g bits as well. The good with this is that it leaves maximum size for hash. The bad is that it is less flexible for adding many new hash algorithms.

2) The proposed new approach: Eat a total of six bits, for Sec and the hash algorithm identifier. 56 bits remain. The good is that this gives more flexibility to allocate hash algorithms, including the ability to independently choose Sec and the algorithm. The bad is that the hash size is decreased.

FWIW, I'm personally in the camp that #1 is still the right approach. We've have 5 entries left:

http://www.iana.org/assignments/cga-message-types/cga-message-types.xml#cga-message-types-3

and even if we some day would run out, there would always be an opportunity to use the last bit combination (111) to denote that the algorithm value would be elsewhere in the address. I admit that my preferences are affected by my view that 59 bits is only borderline secure. So I wouldn't want to reduce it, if it can be avoided.

Jari