[CGA-EXT] Discussion on selection of the Signature Algorithm and Hash functions.

Tony Cheneau <tony.cheneau@it-sudparis.eu> Tue, 01 June 2010 10:12 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id A76D73A6983 for <cga-ext@core3.amsl.com>; Tue, 1 Jun 2010 03:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.351
X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id D7MXtkekeXFy for <cga-ext@core3.amsl.com>; Tue, 1 Jun 2010 03:12:46 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr []) by core3.amsl.com (Postfix) with ESMTP id 937EE3A635F for <cga-ext@ietf.org>; Tue, 1 Jun 2010 03:12:45 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr []) by smtp4.int-evry.fr (Postfix) with ESMTP id 48CBCFE06AF; Tue, 1 Jun 2010 12:12:33 +0200 (CEST)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr []) by smtp2.int-evry.fr (Postfix) with ESMTP id 09146404FD4; Tue, 1 Jun 2010 12:12:27 +0200 (CEST)
Received: from mouette.int-evry.fr (mouette.int-evry.fr []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 0F76C2C18A95; Tue, 1 Jun 2010 12:12:27 +0200 (CEST)
Date: Tue, 1 Jun 2010 12:12:18 +0200 (CEST)
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: cga-ext@ietf.org
Message-ID: <alpine.LNX.2.00.1006011137440.5027@whitebox>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: 09146404FD4.ACD39
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-4.399, requis 6.01, autolearn=not spam, ALL_TRUSTED -1.80, BAYES_00 -2.60)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Subject: [CGA-EXT] Discussion on selection of the Signature Algorithm and Hash functions.
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Jun 2010 10:12:47 -0000

Hello CSI people,

As part of a off-list discussion between Jean-Michel and I (concerning
his previous mail on the list), I would bring a question to the people

It appears there are several approaches proposed to indicate the
algorithms that should be used for creation of the Key Hash field and
Digital Signature field of the RSA Signature Option. I think it would be
good to only find one kind of approach among the different documents.

Here are the current approaches:
1) The approach proposed in draft-ietf-dhc-secure-dhcpv6 (to secure a
Signature Option that is really similar to the RSA Signature Option
defined in RFC 3971) is to use uncorrelated values. More specificaly,
the hash function for the Key Hash field is stored in a HA-id-KH field,
the hash function for the Signature field is stored in a HA-id field and
the Signature Algorithm is stored in a SA-id field.
- it allows a great flexibility
- it seems to be up for the administrator to find out which combination
   of values are safe to use
- binding down attack (could be mitigated by a local policy)

2) The approach proposed in draft-cheneau-csi-send-sig-agility, is to
use a single value that refers to a predefined tuple of (hash function
for the Key Hash field, hash function for the Digital Signature field,
signature algorithm for the digital signature field). We also chose to
force the hash function for the Key Hash field and for the Digital
Signature field to be equals.
- better coherence between hash value and signature algorithm. Some
   combination like SHA-1/ECC might not make sense.
- on an administrator perspective, it seems easier to authorise only a
   set of "value" (i.e. hash function and algorithm) rather than a
   combination of multiple values (previous solution)
- you can encode it using less bits
- binding down attack (mitigated by a local policy)

I think some people of the list (like the authors of
draft-ietf-csi-hash-threat) might have opinions on this.

Of course, I see most of the advantages on my solution, this is why I
bring it to the list, so that we obtain more pro and cons for each
solution (or maybe a third one).