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

Roque Gagliano <roque@lacnic.net> Wed, 09 December 2009 11:14 UTC

Return-Path: <roque@lacnic.net>
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 B6A0D28C0EF for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 03:14:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.048
X-Spam-Level:
X-Spam-Status: No, score=-1.048 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
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 M7d54m7yZOdi for <cga-ext@core3.amsl.com>; Wed, 9 Dec 2009 03:14:39 -0800 (PST)
Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by core3.amsl.com (Postfix) with ESMTP id A31743A690B for <cga-ext@ietf.org>; Wed, 9 Dec 2009 03:14:16 -0800 (PST)
Received: from 85-7-200.lacnic.net.uy (unknown [200.7.85.78]) by mail.lacnic.net.uy (Postfix) with ESMTP id 5A4DB308475; Wed, 9 Dec 2009 09:14:01 -0200 (UYST)
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: multipart/alternative; boundary=Apple-Mail-14-729678094
From: Roque Gagliano <roque@lacnic.net>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C65FB2ECE@NALASEXMB04.na.qualcomm.com>
Date: Wed, 9 Dec 2009 12:13:55 +0100
Message-Id: <B2FDAE8C-CBC8-41BA-8604-B8A79AA763D7@lacnic.net>
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>
To: "Laganier, Julien" <julienl@qualcomm.com>
X-Mailer: Apple Mail (2.1077)
X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information
X-LACNIC.uy-MailScanner: Found to be clean
X-LACNIC.uy-MailScanner-SpamCheck:
X-LACNIC.uy-MailScanner-From: roque@lacnic.net
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 11:14:40 -0000

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

That is something I made clear in the CERT draft.

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

Roque.

-------------------------------------------------------------
Roque Gagliano
LACNIC
roque@lacnic.net
GPG Fingerprint: E929 06F4 D8CD 2AD8 9365  DB72 9E4F 964A 01E9 6CEE