[secdir] Secdir review of draft-ietf-hip-cert-09

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 26 February 2011 22:46 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id EDC4B3A68BC for <secdir@core3.amsl.com>; Sat, 26 Feb 2011 14:46:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.362
X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id iCdebMkmX8+L for <secdir@core3.amsl.com>; Sat, 26 Feb 2011 14:46:31 -0800 (PST)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de []) by core3.amsl.com (Postfix) with ESMTP id 57A6E3A6960 for <secdir@ietf.org>; Sat, 26 Feb 2011 14:46:31 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=PlwknsLVeYuv4EdljpdEY3YSv8yVWdl3zRWLQ261ygAKOyWP1etMfgyJWdMDVP6nxuNtbPkXaWS7TZ2IrVv8JCmzxZiI9/oJZSitNbtGoFgqnFQ2afmC7pf/4TUq8QRs; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 1466 invoked from network); 26 Feb 2011 23:46:42 +0100
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) ( by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 26 Feb 2011 23:46:42 +0100
Message-ID: <4D6982E8.2040607@gondrom.org>
Date: Sat, 26 Feb 2011 22:47:04 +0000
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101206 SUSE/3.1.7 Lightning/1.0b2 Thunderbird/3.1.7
MIME-Version: 1.0
To: secdir@ietf.org
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-hip-cert.all@tools.ietf.org, iesg@ietf.org
Subject: [secdir] Secdir review of draft-ietf-hip-cert-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Feb 2011 22:46:32 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The draft is experimental and specifies for the Host Identity Protocol
(HIP, RFC5201, experimental) the certificate parameter and the error
signaling in case of a failed verification.

>From the security perspective, the considerations in this document
appear to be overall sufficient (note that RFC5201 already covers
several of the security consideration scenarios of the base protocol).

A few small comments:
1. section 2.CERT 2nd paragraph:
"The CERT parameter is covered, when present, by the HIP SIGNATURE field
and is a non-critical parameter."
Not sure it is sufficiently clear what you mean by "covered", maybe the
word "protected" is better in this context.

2. Personally I would have liked to see at least one user scenario for
the CERT with this document, but acknowledge that the document
intentionally excludes such use cases (though I do understand why they
would not want to provide an example).

3. section 2.CERT 8th paragraph: expand "HIT" on first use => "HIT (Host
Identity Tag)" or introduce abbrevation in abstract "Host Identity Tags"
=> "Host Identity Tags (HIT)"

4. the authors should run idnits when submitting the documents:
"There are 2 instances of lines with non-RFC3849-compliant IPv6
addresses in the document.
If these are example addresses, they should be changed.
- line 356: Found possible IPv6 address
'2001:13:724d:f3c0:6ff0:33c2:15d8:5f50' in position 53 in the paragraph;
this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or
RFC 4193's Unique Local Address range FC00::/7.
- and line 537: Found possible IPv6 address
'2001:15:2453:698a:9aa:253a:dcb5:981e' in position 264 in the paragraph;
this doesn't match RFC 3849's suggested 2001:DB8::/32 address range or
RFC 4193's Unique Local Address range FC00::/7."

Best regards, Tobias