[cgasec] Comments and clarification questions on draft-dong-savi-cga-header-03

Tony Cheneau <tony.cheneau@it-sudparis.eu> Wed, 28 July 2010 10:52 UTC

Return-Path: <tony.cheneau@it-sudparis.eu>
X-Original-To: cgasec@core3.amsl.com
Delivered-To: cgasec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BC9F3A6A68 for <cgasec@core3.amsl.com>; Wed, 28 Jul 2010 03:52:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 zE1JuHHpbLcV for <cgasec@core3.amsl.com>; Wed, 28 Jul 2010 03:52:32 -0700 (PDT)
Received: from smtp4.int-evry.fr (smtp4.int-evry.fr [157.159.10.71]) by core3.amsl.com (Postfix) with ESMTP id 50DC73A6A1F for <cgasec@ietf.org>; Wed, 28 Jul 2010 03:52:32 -0700 (PDT)
Received: from smtp2.int-evry.fr (smtp2.int-evry.fr [157.159.10.45]) by smtp4.int-evry.fr (Postfix) with ESMTP id 4C2F9FE0445; Wed, 28 Jul 2010 12:52:54 +0200 (CEST)
Received: from smtp-ext.int-evry.fr (smtp-ext.int-evry.fr [157.159.11.17]) by smtp2.int-evry.fr (Postfix) with ESMTP id 2F2C1404FA1; Wed, 28 Jul 2010 12:26:28 +0200 (CEST)
Received: from dhcp-70d3.meeting.ietf.org (dhcp-70d3.meeting.ietf.org [130.129.112.211]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-ext.int-evry.fr (Postfix) with ESMTP id 0213B2C18A76; Wed, 28 Jul 2010 12:52:48 +0200 (CEST)
Date: Wed, 28 Jul 2010 12:52:52 +0200
From: Tony Cheneau <tony.cheneau@it-sudparis.eu>
X-X-Sender: shad@whitebox
To: draft-dong-savi-cga-header@tools.ietf.org
Message-ID: <alpine.LNX.2.00.1007281251270.1524@whitebox>
User-Agent: Alpine 2.00 (LNX 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner-ID: 2F2C1404FA1.A8075
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-1.101, requis 6.01, BAYES_00 -2.60, HELO_DYNAMIC_DHCP 1.40, RDNS_DYNAMIC 0.10)
X-INT-MailScanner-From: tony.cheneau@it-sudparis.eu
Cc: cgasec@ietf.org
Subject: [cgasec] Comments and clarification questions on draft-dong-savi-cga-header-03
X-BeenThere: cgasec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA-based Security discussion list <cgasec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cgasec>, <mailto:cgasec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cgasec>
List-Post: <mailto:cgasec@ietf.org>
List-Help: <mailto:cgasec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cgasec>, <mailto:cgasec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Jul 2010 10:52:33 -0000

Hello,

I read through your document and I find it pretty interesting.

However, I have some comments or clarification questions:
- Section 7.1: the text references the section 3.1, I think you want to
   reference the section 5 here.
- as you noted, the attacker needs to perform more calculus that the
   node, however, you forget to mention that the SEC parameter has a big
   influence on the address generation time (for the node and for the
   attacker). Each time this parameter is incremented, the address
   generation time is multiplied by 2**16.
- clarification question on the Section 9.3: if I understand correctly,
   you need to have an exchange of 4 messages before you can trust both
   side. What happens if there is less that 4 messages ? For example if
   whole communication was initially a single UDP packet.
- also, in your document, you ask if the Signature Algorithm Agility
   work in CSI may help you. As part of the author of this work, I think
   that indeed this work may interest you.  We have results that proves
   that switching from RSA to ECC has many advantages when using CGAs
   (the advantages are usually well known, such as a shorter key size,
   quicker signature generation, etc).


I'm looking forward to have a good discussion during the bar bof.


Regards,
 	Tony Cheneau