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

"Laganier, Julien" <julienl@qualcomm.com> Fri, 21 May 2010 19:27 UTC

Return-Path: <julienl@qualcomm.com>
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 5E4983A68F8 for <cga-ext@core3.amsl.com>; Fri, 21 May 2010 12:27:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.954
X-Spam-Status: No, score=-104.954 tagged_above=-999 required=5 tests=[AWL=-0.955, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id n7zEspUBTcBQ for <cga-ext@core3.amsl.com>; Fri, 21 May 2010 12:27:53 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com []) by core3.amsl.com (Postfix) with ESMTP id 083FF28C51F for <CGA-EXT@ietf.org>; Fri, 21 May 2010 10:10:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1274461836; x=1305997836; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:acceptlanguage: content-type:content-transfer-encoding:mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20"CGA-EXT@ietf.org"=20<CGA-EXT@ietf.org>|CC:=20"dra ft-cheneau-csi-send-sig-agility@tools.ietf.org"=0D=0A=09< draft-cheneau-csi-send-sig-agility@tools.ietf.org>|Date: =20Fri,=2021=20May=202010=2010:10:27=20-0700|Subject:=20R eview=20of=20draft-cheneau-csi-send-sig-agility-01 |Thread-Topic:=20Review=20of=20draft-cheneau-csi-send-sig -agility-01|Thread-Index:=20Acr5CIJXe/IOpokTQGmywGbGX6vS2 w=3D=3D|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F 00A75BB9@NALASEXMB04.na.qualcomm.com>|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IqTtw1BbrQ2tLwAoqEEI47y8BCVcPZdyAy8TyPRAJAE=; b=j9kZNOiC8IJ8gaBUVFQ9qFJD1TpEBqpna5wu8hJD8I3UN/SAObI6JtHd Zv2K6ybLzjqnKFDWvDY9XS9ozsrTtq2x7miwotsTxyvRbpHXAjzZSnG4E fz47Bmq9lqMFlhd50EDwMlZBW3XlDOP1mFEpIM6n2D4XHzChykt+VjQXs c=;
X-IronPort-AV: E=McAfee;i="5400,1158,5989"; a="42168506"
Received: from ironmsg02-l.qualcomm.com ([]) by wolverine01.qualcomm.com with ESMTP; 21 May 2010 10:10:28 -0700
X-IronPort-AV: E=Sophos;i="4.53,278,1272870000"; d="scan'208";a="65279835"
Received: from nasanexhub03.na.qualcomm.com ([]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 May 2010 10:10:28 -0700
Received: from nasanexhc08.na.qualcomm.com ( by nasanexhub03.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id; Fri, 21 May 2010 10:10:28 -0700
Received: from nalasexhub01.na.qualcomm.com ( by nasanexhc08.na.qualcomm.com ( with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 21 May 2010 10:10:28 -0700
Received: from NALASEXMB04.na.qualcomm.com ([]) by nalasexhub01.na.qualcomm.com ([]) with mapi; Fri, 21 May 2010 10:10:28 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "CGA-EXT@ietf.org" <CGA-EXT@ietf.org>
Date: Fri, 21 May 2010 10:10:27 -0700
Thread-Topic: Review of draft-cheneau-csi-send-sig-agility-01
Thread-Index: Acr5CIJXe/IOpokTQGmywGbGX6vS2w==
Message-ID: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "draft-cheneau-csi-send-sig-agility@tools.ietf.org" <draft-cheneau-csi-send-sig-agility@tools.ietf.org>
Subject: [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: Fri, 21 May 2010 19:27:55 -0000

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.

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.)

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.

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.

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.

- 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.