Re: [secdir] Secdir review of draft-housley-ltans-oids-00

Russ Housley <housley@vigilsec.com> Fri, 12 July 2013 21:57 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 211E421F9FE7; Fri, 12 Jul 2013 14:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level:
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMn5DQJ4MW0T; Fri, 12 Jul 2013 14:57:44 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id D98BB21F9FE9; Fri, 12 Jul 2013 14:57:43 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id A362AF240B0; Fri, 12 Jul 2013 17:58:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id RgeRjoHDeLQ6; Fri, 12 Jul 2013 17:57:26 -0400 (EDT)
Received: from [192.168.2.109] (pool-96-241-163-41.washdc.fios.verizon.net [96.241.163.41]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id CEB02F2408B; Fri, 12 Jul 2013 17:58:27 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <20960.30655.526275.938616@fireball.kivinen.iki.fi>
Date: Fri, 12 Jul 2013 17:57:40 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0825B2AF-4B45-4B1A-888B-829D03D32AFB@vigilsec.com>
References: <20960.30655.526275.938616@fireball.kivinen.iki.fi>
To: Tero Kivinen <kivinen@iki.fi>
X-Mailer: Apple Mail (2.1085)
Cc: IESG <iesg@ietf.org>, IETF SecDir <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-housley-ltans-oids-00
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 12 Jul 2013 21:57:49 -0000

Tero:

Thanks for the review.

There are two ASN.1 flavors, and the documents provide a module for each of them.  Yes, the ITU-T really did make a second flavor without considering backward compatibility.  People that implement with ASN.1 know which flavor their tools use.

I do not think that the document that established a registry ought to point to the security considerations of the protocols that make use of the registry.  A protocol implementor needs to read the protocol document.

Since the IESG designates all experts (and may also remove them), Expert Review is sufficient.

Russ



On Jul 12, 2013, at 5:40 PM, Tero Kivinen wrote:

> 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.
> 
> This document fills up the LTANS ASN.1 OID arc in the IANA registry.
> It adds some values and points them to published RFCs, and also
> reserves some values where there was never RFC published for those
> protocols.
> 
> For some reason some of values include two OIDs, one for the 1997  and
> another 1988 ASN.1 syntax. I do not know enough of LTANS to understand
> why this distinction needs to be made in the OIDs themselves, I only
> assumed this affected the compilers and textual descriptions of the
> ASN.1 stuff, but perhaps OIDs here are used to indicate some ASN.1
> text module or something.
> 
> The security considerations section is very short:
> 
>   This document populates an IANA registry, and it raise no new
>   security considerations.  The protocols that specify these values
>   include the security considerations associated with their usage.
> 
> While this is true, it might be helpful to add references to the
> actual protocols it is refering here. The list of relevant RFCs can be
> found in the IANA considerations section, but adding pointers here
> might be helpful. I have not checked out whether the security
> considerations sections in those documents contain anything useful.
> 
> One odd thing is that all registries are marked as "Expert Review or
> IESG Approval", but which one of those is used? Is this supposed to
> mean that if IESG appoints a designed expert for these, then he does
> checks the updates, but if not, then IESG approval is needed? Or is it
> mean to say that even when there is designated expert, the IESG and
> ignore him and do the approval themselves (in which case I Would ask
> what is the point of having the designated expert)?
> 
> Usually there is only one way of doing the IANA updates.
> -- 
> kivinen@iki.fi
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview