Re: [secdir] SECDIR review of draft-mahesh-etsi-urn-03

Mahesh Jethanandani <mjethanandani@gmail.com> Tue, 24 July 2018 21:37 UTC

Return-Path: <mjethanandani@gmail.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 C6687130E8F; Tue, 24 Jul 2018 14:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4W2VZhLXASyp; Tue, 24 Jul 2018 14:37:53 -0700 (PDT)
Received: from mail-pf1-x441.google.com (mail-pf1-x441.google.com [IPv6:2607:f8b0:4864:20::441]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BF1124C04; Tue, 24 Jul 2018 14:37:53 -0700 (PDT)
Received: by mail-pf1-x441.google.com with SMTP id k19-v6so1156206pfi.1; Tue, 24 Jul 2018 14:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CmHpisiEUdP66AhVBymW9343t7wUABBgwNu4RtgGS+0=; b=kU4stuEWh+AxHp/7kIKzwW79ubL3K2ig7J3oI6KmAIH7zToXkcVZ7t485ylY9sNdj1 aLbcgd6u0BU4f/zEH65rlU1YFmKvH4oFRhqKXIuP/w+uLWRRLkEtT2ZvMH7oGlpMNUEM PO+5xzXfeoUxGZX3kaySk8BFUrFMGxTo1a547v68QvaecFgnN/PK7n3M9LcweHD0m74a YVkH+H+IkLpgQ5/XTkkoi4onrE+TXsWC2/JYx4RlOoI4IHFdcjz09FCO47o1PDqdYJFZ uq4ZqMOaJlazqKrtfymIy6m0Kctu34sQWL8X8VbYBWwFDmlOvPMb/VoL4kuqBVDNB7QX bcaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CmHpisiEUdP66AhVBymW9343t7wUABBgwNu4RtgGS+0=; b=XS273WIBq8xCHpMTxbRrhNLXmJco3zCxY7SftV41TcMX11fFIj9CQymvU84wZLe1wB b3WyhvyPNmM184aiq9Izf4r7obdiHMMYKLvc4gNxFMAGTAOkZJ5Rga9NKPYmwCO2Jvgr joqQE6w9cjDEKBJPkQ+BpRxjSzq1VkRwMftAQ+L68RItCKoAk56J2hJOC5k7NOVeaH/F 9af8d4hSpR0EcELLVNhM0FSBejAnJMJIc9ZYZb+QkCnQV09x7WK/F7DwKI1R/pCWgqFx vqMhgIfQ/7dR5z/64yGPz1jqsnUB1CF33anXaZWZnFir2t9lLwEhQY5ytUU0pZsuRXrC N9xQ==
X-Gm-Message-State: AOUpUlGAc09RmmFV1ssagS3FxvKNKET7908s2ui0BRR8adjcodX0HEaj AJk42E7LLHtcWEPpTFqfYME=
X-Google-Smtp-Source: AAOMgpekxFFvdsEYYzyYdFA0F/FfcsootMINGsvzX9FDO9yeokllNGu2Jtezl6AWv3Z8aP2qmmezmw==
X-Received: by 2002:aa7:88d3:: with SMTP id p19-v6mr19371696pfo.160.1532468272581; Tue, 24 Jul 2018 14:37:52 -0700 (PDT)
Received: from ?IPv6:2601:647:4700:1280:3596:f6c9:d32c:c4dd? ([2601:647:4700:1280:3596:f6c9:d32c:c4dd]) by smtp.gmail.com with ESMTPSA id d81-v6sm32015287pfj.122.2018.07.24.14.37.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Jul 2018 14:37:51 -0700 (PDT)
From: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-Id: <52B57BE1-B92E-42C2-8F7F-815A7658A903@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F9081262-B1F5-4696-902E-301A5BBD912F"
Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\))
Date: Tue, 24 Jul 2018 14:37:50 -0700
In-Reply-To: <5B567AA3.1010902@gmail.com>
Cc: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-mahesh-etsi-urn.all@ietf.org
To: Chris Lonvick <lonvick.ietf@gmail.com>
References: <5B567AA3.1010902@gmail.com>
X-Mailer: Apple Mail (2.3445.8.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/86zP4eV3jlbrPjgHpVB0BMtA4ZM>
Subject: Re: [secdir] SECDIR review of draft-mahesh-etsi-urn-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 24 Jul 2018 21:37:56 -0000

Hi Chris,

> On Jul 23, 2018, at 6:02 PM, Chris Lonvick <lonvick.ietf@gmail.com>; wrote:
> 
> Hi,
> 
> 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 summary of the review is Ready with Issues.
> 
> I am not that familiar with creating and maintaining URNs so please set me straight and move on if I'm off base here. 
> 
> Section 2, "URN Specification for ETSI" contains the following:
> 
> "ETSI will manage resource classes using the "etsi" NID and will be the authority for managing resources and associated subsequent strings. ETSI will guarantee the uniqueness of the strings themselves, or it may permit secondary responsibility for certain defined resources." 
> 
> But then says:
> 
> "ETSI may allow for use of experimental type values for testing purposes only. Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings."
> 
> It looks like RFC 8141 gives guidance that experimental use of URN namespaces is to be done using RFC 6963 (URNs for "Examples".) RFC 8184 does not address establishing or using namespaces under the subsequent strings for experimental use, but I could see that the registered owner of the namespace could make a designation for that purpose. That being said, I think that the two statements above are in conflict in the document and should be clarified.

Not necessarily.

RFC6963 says that there are three types of namespaces, formal, informal and experimental. What this draft is requesting for is the formal namespace. The RFC also says that experimental namespaces are by definition unregistered. That there is no issuing authority for experimental URNs. The owner of the NID therefore is not required to keep track of experimental namespaces. 

> 
> Perhaps it would be better to reconstruct the second paragraph to say something like:
> 
> "ETSI may allow for use of experimental type values for testing purposes only. Some experimentation may be controlled by ETSI within a subsequent string to ensure that there will be no namespace collisions among participants. Other experimentation may be controlled within a secondary namespace that may allow collisions, but this experimental use will be constrained. All other experimentation must follow the guidance set forth in RFC 6963.”

How about this?

OLD:

ETSI may allow for use of experimental type values for testing purposes only. Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings.

NEW:

ETSI may allow for use of experimental type values for testing purposes only. Note that using experimental types may create collision as multiple users may use the same values for different resources and specific strings. All experimentation must follow the guidance set forth in RFC 6963.

> 
> Just as a nit, the Security Considerations section should be revised as it seems to be a bit unclear.
> Current:
>    There are no additional security considerations other than those
>    described above, and are normally associated with the use and
>    resolution of URNs in general, which are described in Function
>    Requirements for URN [RFC1737 <https://tools.ietf.org/html/rfc1737>], Uniform Resource Names (URNs)
>    [RFC8141 <https://tools.ietf.org/html/rfc8141>].
> 
> Suggested:
>    There are no additional security considerations other than those
>    described above, and those normally associated with the use and
>    resolution of URNs in general. These are generally described in Functional
>    Requirements for Uniform Resource Names [RFC1737 <https://tools.ietf.org/html/rfc1737>], and Uniform Resource Names (URNs)
>    [RFC8141 <https://tools.ietf.org/html/rfc8141>].

Ok.

Thanks.

> 
> Best regards, Chris

Mahesh Jethanandani
mjethanandani@gmail.com