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

"Laganier, Julien" <julienl@qualcomm.com> Fri, 21 May 2010 21:12 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 [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D8F3A6A8B for <cga-ext@core3.amsl.com>; Fri, 21 May 2010 14:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.383
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CEDMvMuKHxGi for <cga-ext@core3.amsl.com>; Fri, 21 May 2010 14:12:18 -0700 (PDT)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 400B03A6A1A for <CGA-EXT@ietf.org>; Fri, 21 May 2010 14:11:48 -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=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<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=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 00A75BD5@NALASEXMB04.na.qualcomm.com>|References:=20<BF34 5F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qua lcomm.com>|In-Reply-To:=20<BF345F63074F8040B58C00A186FCA5 7F1F00A75BB9@NALASEXMB04.na.qualcomm.com> |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 ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com 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 nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 May 2010 12:47:17 -0700
Received: from nasanexhc09.na.qualcomm.com (172.30.39.8) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 21 May 2010 12:47:17 -0700
Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhc09.na.qualcomm.com (172.30.39.8) with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 21 May 2010 12:47:17 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Fri, 21 May 2010 12:47:17 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: "CGA-EXT@ietf.org" <CGA-EXT@ietf.org>
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: <BF345F63074F8040B58C00A186FCA57F1F00A75BD5@NALASEXMB04.na.qualcomm.com>
References: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1F00A75BB9@NALASEXMB04.na.qualcomm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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: 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: 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.

--julien

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
> CGA-EXT@ietf.org
> https://www.ietf.org/mailman/listinfo/cga-ext