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

"Laganier, Julien" <> Fri, 21 May 2010 21:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 17D8F3A6A8B for <>; Fri, 21 May 2010 14:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.383
X-Spam-Status: No, score=-106.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CEDMvMuKHxGi for <>; Fri, 21 May 2010 14:12:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 400B03A6A1A for <>; Fri, 21 May 2010 14:11:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1274476305; x=1306012305; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to: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<> |To:=20""=20<>|CC:=20"dra"=0D=0A=09<>|Date: =20Fri,=2021=20May=202010=2012:47:15=20-0700|Subject:=20R E:=20Review=20of=20draft-cheneau-csi-send-sig-agility-01 |Thread-Topic:=20Review=20of=20draft-cheneau-csi-send-sig -agility-01|Thread-Index:=20Acr5CIJXe/IOpokTQGmywGbGX6vS2 wAFKvvw|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1F>|References:=20<BF34>|In-Reply-To:=20<BF345F63074F8040B58C00A186FCA5> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=I5PCdnkkrH9srcoPpAfLj14YcZHhpVNTLizbTQOuVQ0=; b=qmPXcDNJI/NBrva7X2S9xhZ9m1AqF2yrx5aXcTR9RMH1Yud3+Vzctu9q Mkj1OTAU5pftQjk6kETYN2h+he95qyS9Ewiq4cl0WW3lAewqdQCigtBzE md+ETkUH5GWWqTeyxXKSEgTOAdAGQrkLr168F6a2KoYnrU1rhvvLNhmxp 8=;
X-IronPort-AV: E=McAfee;i="5400,1158,5989"; a="42182470"
Received: from ([]) by with ESMTP; 21 May 2010 12:47:17 -0700
X-IronPort-AV: E=Sophos;i="4.53,278,1272870000"; d="scan'208";a="41541087"
Received: from ([]) by with ESMTP/TLS/RC4-MD5; 21 May 2010 12:47:17 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 21 May 2010 12:47:17 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 21 May 2010 12:47:17 -0700
Received: from ([]) by ([]) with mapi; Fri, 21 May 2010 12:47:17 -0700
From: "Laganier, Julien" <>
To: "" <>
Date: Fri, 21 May 2010 12:47:15 -0700
Thread-Topic: Review of draft-cheneau-csi-send-sig-agility-01
Thread-Index: Acr5CIJXe/IOpokTQGmywGbGX6vS2wAFKvvw
Message-ID: <>
References: <>
In-Reply-To: <>
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: "" <>
Subject: Re: [CGA-EXT] Review of draft-cheneau-csi-send-sig-agility-01
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 May 2010 21:12:20 -0000

Someone pointed out that my previous message (below) listed the "simple requirements" but omitted a description of a "simpler approach" that I recommended we follow. That was actually intentional -- I thought a simpler approach would easily be derived from simple requirements. 

FWIW - a strawman that seems to fulfill simpler requirements would be:

- define NewSignature and NewCGA options that include the algorithm in use and are used in place of CGA and RSA Signature options when the algorithm in use is not RSA. 

- NewSignature and NewCGA options will be ignored by legacy nodes (i.e., conforming to RFC 3971) and thus messages carrying them will be treated as unsecured by these nodes. 

- specify NewSignature and NewCGA receiver processing such that a node that doesn't support said algorithm treats the message as unsecured.


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.
> 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.
> --julien
> _______________________________________________
> CGA-EXT mailing list