Re: [secdir] secir review of draft-ietf-6man-text-addr-representation-04

Seiichi Kawamura <kawamucho@mesh.ad.jp> Mon, 01 February 2010 00:30 UTC

Return-Path: <kawamucho@mesh.ad.jp>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53D1A3A67FC; Sun, 31 Jan 2010 16:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level:
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
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 Y+w4fLjOfoGw; Sun, 31 Jan 2010 16:30:12 -0800 (PST)
Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 27ECB3A69F5; Sun, 31 Jan 2010 16:30:11 -0800 (PST)
Received: from mailgate3.nec.co.jp ([10.7.69.161]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o110UgLu029103; Mon, 1 Feb 2010 09:30:42 +0900 (JST)
Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o110Ug929454; Mon, 1 Feb 2010 09:30:42 +0900 (JST)
Received: from bgas200085.sys.biglobe.nec.co.jp (bgas200085.sys.biglobe.nec.co.jp [10.82.141.45]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o110UgQT003265; Mon, 1 Feb 2010 09:30:42 +0900 (JST)
Received: from bsac29088.sys.biglobe.nec.co.jp (localhost [127.0.0.1]) by bgas200085.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110Ufhd015491; Mon, 1 Feb 2010 09:30:41 +0900
Received: from mail.sys.biglobe.nec.co.jp (bgsx5626.sys.biglobe.nec.co.jp [10.18.151.10]) by bsac29088.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110UfNI018349; Mon, 1 Feb 2010 09:30:41 +0900
Received: from [127.0.0.1] (edonet065.sys.biglobe.nec.co.jp [10.19.137.65]) (authenticated bits=0) (envelope-from kawamucho@mesh.ad.jp) by mail.sys.biglobe.nec.co.jp (BINGO/BINGO/06101717) with ESMTP id o110UfVx001500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Feb 2010 09:30:41 +0900
Message-ID: <4B6620B0.6020208@mesh.ad.jp>
Date: Mon, 01 Feb 2010 09:30:40 +0900
From: Seiichi Kawamura <kawamucho@mesh.ad.jp>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tom Yu <tlyu@mit.edu>
References: <ldvhbq4fe86.fsf@cathode-dark-space.mit.edu>
In-Reply-To: <ldvhbq4fe86.fsf@cathode-dark-space.mit.edu>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 01 Feb 2010 08:09:17 -0800
Cc: 6man-chairs@tools.ietf.org, draft-ietf-6man-text-addr-representation@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secir review of draft-ietf-6man-text-addr-representation-04
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: Mon, 01 Feb 2010 00:30:14 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom

Thanks for your comments.
I will add to the Security Considerations
a short paragraph to note on this.

"This document notes on some examples where IPv6 addresses are
compared in textual format. The example on Section 3.2.5 is one
that may cause a security risk if used for access control.
Comparison of X.509 data should be done as binary.

Also, care should be taken in any operational situation where security
measures require the handling of an address in text."

> Editorial:
>
> In Section 3.3.2, I believe the claim that IPv4 addresses cannot be
> abbreviated is false.  Historically, BSD implementations of textual
> IPv4 address parsing have accepted a number of variant abbreviated
> notations.  I think they have generally output canonical dotted-quad
> IPv4 addresses though.

Ahh. needs a bit or rewording. Thank you.

Regards,
Seiichi

Tom Yu wrote:
> This draft indicates that it has no security considerations.  I think
> that conflicts with Section 3.2.5, which gives an example of
> inappropriate (textual) verification of IPv6 addresses in an X.509
> certificate.  Although (in my understanding) IPv6 addresses in X.509
> certificates are in binary form and probably should be compared as
> such, if the authors feel the need to explicitly call out an example
> of inappropriate textual verification of addresses, which could have
> security consequences if the address values in question are used for
> access control.
> 
> The text in Section 3.3.3 about network abuse reporting would also
> appear to have some operational (but probably not protocol) security
> consequences, especially if a network operator would need to respond
> rapidly to an ongoing attack.
> 
> Editorial:
> 
> In Section 3.3.2, I believe the claim that IPv4 addresses cannot be
> abbreviated is false.  Historically, BSD implementations of textual
> IPv4 address parsing have accepted a number of variant abbreviated
> notations.  I think they have generally output canonical dotted-quad
> IPv4 addresses though.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAktmILAACgkQcrhTYfxyMkKNZACgjA+1rE6ifRKU91jtgLjylI8y
AZ0An1sOPHmWo3nBkILac/gKrKjdWuMK
=BiFx
-----END PGP SIGNATURE-----