Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-01

"Laganier, Julien" <julienl@qualcomm.com> Wed, 09 December 2009 17:01 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 AF23F28C1A2 for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 09:01:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.625
X-Spam-Level:
X-Spam-Status: No, score=-103.625 tagged_above=-999 required=5 tests=[AWL=-1.026, BAYES_00=-2.599, 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 CXk-IBN0Nzv7 for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 09:01:14 -0800 (PST)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 889B828C19C for <cga-ext@ietf.org>; Wed, 9 Dec 2009 09:01:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1260378064; x=1291914064; 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:x-ironport-av; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Roque=20Gagliano=20<roque@lacnic.net>|CC:=20"draft -ietf-csi-proxy-send@tools.ietf.org"=0D=0A=09<draft-ietf- csi-proxy-send@tools.ietf.org>,=0D=0A=20=20=20=20=20=20 =20=20"cga-ext@ietf.org"=0D=0A=09<cga-ext@ietf.org>|Date: =20Wed,=209=20Dec=202009=2009:00:59=20-0800|Subject:=20RE :=20[CGA-EXT]=20Review=20draft-ietf-csi-proxy-send-01 |Thread-Topic:=20[CGA-EXT]=20Review=20draft-ietf-csi-prox y-send-01|Thread-Index:=20Acp4wMl+JnGSdj/8Q+maARSMTXlnSgA LcgdA|Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C65 FB3043@NALASEXMB04.na.qualcomm.com>|References:=20<alpine .LNX.2.00.0911191100150.7833@whitebox>=0D=0A=09<BF345F630 74F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm .com>=0D=0A=09<alpine.LNX.2.00.0911201144010.7546@whitebo x>=0D=0A=09<BF345F63074F8040B58C00A186FCA57F1C65FB277D@NA LASEXMB04.na.qualcomm.com>=0D=0A=09<alpine.LNX.2.00.09112 11025090.11248@localhost.localdomain>=0D=0A=09<BF345F6307 4F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm. com>=0D=0A=09<alpine.LNX.2.00.0911242317130.11124@localho st.localdomain>=0D=0A=09<BF345F63074F8040B58C00A186FCA57F 1C65FB2A51@NALASEXMB04.na.qualcomm.com>=0D=0A=09<alpine.L NX.2.00.0911260951580.7596@whitebox>=0D=0A=09<37915D90-B2 46-48E4-9C7B-69DAF54FA43A@lacnic.net>=0D=0A=09<BF345F6307 4F8040B58C00A186FCA57F1C65FB2ECE@NALASEXMB04.na.qualcomm. com>=0D=0A=20<B2FDAE8C-CBC8-41BA-8604-B8A79AA763D7@lacnic .net>|In-Reply-To:=20<B2FDAE8C-CBC8-41BA-8604-B8A79AA763D 7@lacnic.net>|Accept-Language:=20en-US|Content-Language: =20en-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20text/plain=3B=20 charset=3D"us-ascii"|Content-Transfer-Encoding:=20quoted- printable|MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee =3Bi=3D"5400,1158,5826"=3B=20a=3D"29472707"; bh=KY6AwaZjpbM2Fao8bFsxWg11J/zhOAb3QIroZ6JW3mI=; b=tllz9ZSyV8v9QtCcQcDBNPzTD9ueX07pgRMPAfxKdsJmjggIZIqmBiWe wDDqO/mEDqpiktDMG1CWEHFhxXDMq2f4EhwIL25mdvJmmFfAc63BNOVON GdgPS54eVIZ/lA2CyTdo9vf6CW6KMgxGe/UmW8J2aqGnXI08PfviAYPhQ s=;
X-IronPort-AV: E=McAfee;i="5400,1158,5826"; a="29472707"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine02.qualcomm.com with ESMTP; 09 Dec 2009 09:01:03 -0800
Received: from msgtransport02.qualcomm.com (msgtransport02.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB9H12VG003572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2009 09:01:02 -0800
Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by msgtransport02.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id nB9H112w010232 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 9 Dec 2009 09:01:01 -0800
Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 9 Dec 2009 09:01:01 -0800
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.118]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 9 Dec 2009 09:01:01 -0800
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Roque Gagliano <roque@lacnic.net>
Date: Wed, 9 Dec 2009 09:00:59 -0800
Thread-Topic: [CGA-EXT] Review draft-ietf-csi-proxy-send-01
Thread-Index: Acp4wMl+JnGSdj/8Q+maARSMTXlnSgALcgdA
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C65FB3043@NALASEXMB04.na.qualcomm.com>
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911201144010.7546@whitebox> <BF345F63074F8040B58C00A186FCA57F1C65FB277D@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2A51@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911260951580.7596@whitebox> <37915D90-B246-48E4-9C7B-69DAF54FA43A@lacnic.net> <BF345F63074F8040B58C00A186FCA57F1C65FB2ECE@NALASEXMB04.na.qualcomm.com> <B2FDAE8C-CBC8-41BA-8604-B8A79AA763D7@lacnic.net>
In-Reply-To: <B2FDAE8C-CBC8-41BA-8604-B8A79AA763D7@lacnic.net>
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-ietf-csi-proxy-send@tools.ietf.org" <draft-ietf-csi-proxy-send@tools.ietf.org>, "cga-ext@ietf.org" <cga-ext@ietf.org>
Subject: Re: [CGA-EXT] Review draft-ietf-csi-proxy-send-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: Wed, 09 Dec 2009 17:01:15 -0000

Hi Roque -

> Julien,
>
>
> > Well, actually that's a feature of CGA's, one can show proof-of-ownership by signing with the CGA's private key. I own my CGA because I generated it and the corresponding key pair, and you do not own it and you can't show proof of ownership because you don't have the private key.
> >
> > So I think we want to keep using that term.
> >
> > I can agree that we don't want to talk about a prefix owner, though, but I don't think we're doing that in the document. 
>
> I understand, but CGA only refers to IIDs not to the complete address (including the prefix). 

CGA generation _and_ proof-of-ownership are tied to the CGA's prefix thus I disagree with your statement above.
 
> Coming from the addressing world I have to make the distinction. In our world we talk about "right of use" and not ownership. This means, I have the right of USING this CGA because I have possession of the correspondent private key.

A first observation is that the term ownership is used extensively in the CGA related literature.
 
That being said, you seem to be opposing ownership and right of use in this context when there's no need to. There's quite a difference between the two and not specific to that context. I might well own something and have no right to use it, e.g., a car, a plane, a gun.

So in terms of prefix I agree that you want to use right of use rather than ownership, but in terms of CG-addresses, IMHO we do want to say ownership.

> That is something I made clear in the CERT draft.

But the focus of the CERT draft is on delegating authorization to advertize/use prefixes or addresses that are NOT cryptographically generated, thus there's no ownership involved.

> > The lack of algorithm agility is generic to SEND and not specific to the Secure Proxy ND mechanism. When the WG concludes on how to move forward with algorithm agility, we can publish an RFC updating both RFC3971 and this to be RFC to add algorithm agility. 
> 
> So, we know there is a problem and probably know that SEC ADs are looking at these particular issues, however we would to advance this draft to the IESG hopping that it passes their LC with the promise to solve the issue later on? I only have been in CSI for a couple of months but does not sound proper IETF process to me.
>
> The agility discussion also included a signaling between the parties in order to select which algorithm to use. What we can do while that discussion is not over in the WG is to make sure that new SEND options have the possibility of identifying which algorithms each party are using, leaving the signaling part for later. This is similar to DNSSEC where in order to change from SHA-1 to SHA-256 probably all signatures will be for a while duplicated in the zone files.

Would inclusion of an algorithm field in the PSO solve your concern?

--julien