Re: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01

Tony Cheneau <tony.cheneau@it-sudparis.eu> Mon, 24 May 2010 13:27 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 [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DABC63A6C00 for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 06:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.799
X-Spam-Level:
X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_50=0.001, HELO_EQ_FR=0.35]
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 W0WdMQyTrn-V for <cga-ext@core3.amsl.com>; Mon, 24 May 2010 06:27:49 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 7F6ED3A6BFB for <cga-ext@ietf.org>; Mon, 24 May 2010 06:27:49 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 3F837FE05AB; Mon, 24 May 2010 15:27:41 +0200 (CEST)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id B70CD404FA8; Mon, 24 May 2010 15:27:36 +0200 (CEST)
Received: from alf94-6-82-226-232-167.fbx.proxad.net (alf94-6-82-226-232-167.fbx.proxad.net [82.226.232.167]) (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 ABFBD2C181BB; Mon, 24 May 2010 15:27:36 +0200 (CEST)
Date: Mon, 24 May 2010 15:27:39 +0200 (CEST)
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@localhost.localdomain
To: "Laganier, Julien" <julienl@qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com>
Message-ID: <alpine.LNX.2.00.1005241432380.18237@localhost.localdomain>
References: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: B70CD404FA8.AA0D4
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=0.805, requis 6.01, BAYES_00 -2.60, FH_HELO_EQ_D_D_D_D 0.00, HELO_DYNAMIC_IPADDR 2.43, RCVD_IN_SORBS_DUL 0.88, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: "CGA-EXT@ietf.org" <CGA-EXT@ietf.org>, "draft-cheneau-csi-send-sig-agility@tools.ietf.org" <draft-cheneau-csi-send-sig-agility@tools.ietf.org>
Subject: Re: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01
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: Mon, 24 May 2010 13:27:51 -0000

Hello Julien,

Thank you for reviewing our document.

Comments below:

On Fri, 21 May 2010, Laganier, Julien wrote:

> I have reviewed "Signature Algorithm Agility in the Secure Neighbor Discovery Protocol" and have the following comments. I am not going to comment on the specifics of the protocol extension because I disagree with the overall approach.
OK.

> I do not think it's reasonable for an extension to a relatively simple security protocol (SEND) to introduces 4 different types of hosts, 4 different type of routers, some of which are said to be "hard to secure" and recommended to avoid, while another who rely on unspecified redirection mechanisms between CGAs, and some combinations of these hosts and routers leading to undetectable failure modes (at least from what I understood.)
It appears, from your comment and Jean-Michel's review that this part of
the document (section 2.1.1 and 2.1.2) is currently quite confusing.
Section 2.1.1 is about what we might expect the nodes to do. Not about
what we actually do here in this document. It is just a classification
work so we can state what can be done, with some drawbacks, and what we
actually propose here in this document (H1, H2, R1, R2 and R4 type nodes).
I am currently reworking these sections so, hopefully, the text will be
less confusing in the future.


> I think most of the complexity and drawbacks of the proposal stems from the requirement that signature agile nodes be able to negotiate a common signature algorithm, which I think is unreasonable when the protocol employs multicast/broadcast (thus reaches multiples nodes which might support different algorithms) and when the algorithm is somehow "hardcoded" in the CG address used by a node thus adding an additional level of constraint.
I somewhat agree with you. Too much negotiation will be a burden on the
nodes and can involve security issues.
However, I would like to say, that: for routers, the multicast scenario
seems fairly easy.  A router can generate two CGA addresses, one based
on RSA, the other one on ECC and send regularly messages signed with
both algorithm. Both addresses are viewed as separate entities and it
only involves the router sending twice as much Router Advertisement
messages.
Also, we are currently shifting the usage of the Supported Signature Option.
It was previously an option to perform negotiation. Now, it is more
focused on diagnostic (i.e. it helps an administrator of a node to
understand why it fails to communicate with neighboring nodes).

> In this situation, the only reasonable chance for ND to operate securely is that most of the nodes on a link support the same signature algorithm (e.g., ECDSA), other minority nodes falling back to mixed mode.
I think we agree on the fall-back mechanism.

> In light of this, I recommend a simpler approach to be taken based on two simple requirements:
>
> - it shall be possible for a node supporting the signature agility extension to use a public key algorithm other than RSA for generation/verification of a signature/CGA.
>
I agree with this point, but I will add a little nuance here: a RSA node
could sign using RSA/SHA-1 or RSA/SHA-256.

> - an ND message sent from a CGA based on a public key algorithm that is not supported by the receiver, and signed using that same algorithm shall be treated as insecure by the receiver as per RFC3971, i.e., it shall not be discarded.
I do not see why I should threat a message as insecure if I can verify
the signature it is protected with. This has nothing to do with the
algorithm I can sign with (which are linked to the CGA or the
Public Key that is pointed by the Key Hash field of the XXX Signature
Option). I think it just depends on the capabilities of a node (crypto
library, CPU power, etc).

Thanks for your really appreciated inputs.

Regards,
 	Tony