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

Chris Lonvick <lonvick.ietf@gmail.com> Tue, 24 July 2018 01:02 UTC

Return-Path: <lonvick.ietf@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 20357130FCB; Mon, 23 Jul 2018 18:02:38 -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 4dS0Oepage4k; Mon, 23 Jul 2018 18:02:32 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 75EF9130F82; Mon, 23 Jul 2018 18:02:29 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id s8-v6so1014075ybe.8; Mon, 23 Jul 2018 18:02:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=s1DyOckFRuoMdiu0oJyeLa2KBFrfM1QArCpf8i27zKE=; b=GO4j5hWa3Ifs2KNOFcbYSR3OZJpaTrOaiG5L/pcV8h4nUUMHlhHuky3/YhULSeNgvJ 5eMdBHkp3IYOPLivirA2kGjUBrTK4BvCLICj7rSit1UnpfKO7qDBvEP2xzFjg6ySv4I6 13D2FIi1K/G8hYop9ohgq+6CpJTz0An4ttn9J1qGkfw4CaH1ihB75aOQ4jL9QH6nplw6 76GeAmd7GfYCkYKro3A5G/PrJjTPZOAh9dqK58dARYefoW7XrEhTyuYKy9iA+xWTykH5 oykv6j4LXCWhTFoZe3a7ABQq+Zdxs5lphjNOgw2ZSUs1HTcKauobQ01/QlONOYwBMN3c NZww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=s1DyOckFRuoMdiu0oJyeLa2KBFrfM1QArCpf8i27zKE=; b=PLP8V98GvcGbLv+NU58oUvTgRg+1rrRk/F0UejMK1IdV4ChfguyUEI5VeeUWOCF3jU /YwvnFOWSpDN4DvZJd4rHchQx3S85mO3thyEzpWhavzuBY0LIW9sFLrj/VqDyR9yce7J XsOkGmVfbtA4No5Jo+SIiQRD7Lpz2rlNjRV8A+v2X3ScCpP+mLBHzIB8ckX2OcJO4Ce/ ioEJPU8SiyTgyk1cM1TWzrmLqo4eN6IDNVCp/BUKoUVXNHX5x0Z04oHnCVx+h4cdcqEh 8MQNULxCGCy+Xjv8hzNs+TYO+PgfTKUjB5i5DNCIoYLXHwGxW8bvvFR9hbeBZB6zwSGU 4MQA==
X-Gm-Message-State: AOUpUlE3qkeeVO/VtTwHevfWCTErBHIyNd0XCuU58LkFDiRnKrUPQ4MT nk7XHJVXl6QIlXQbcJ0/HAR8vb6w
X-Google-Smtp-Source: AAOMgpdJTNzbtRAO2Yc6A6bwxJXuoHxZQ3oQfTUqOR6VxYiEJI+fgC/P6Yv20uJweQO08b80xZQOqQ==
X-Received: by 2002:a25:e6c6:: with SMTP id d189-v6mr8114809ybh.341.1532394148345; Mon, 23 Jul 2018 18:02:28 -0700 (PDT)
Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:6089:f65:f180:8308]) by smtp.googlemail.com with ESMTPSA id r17-v6sm2712099ywa.36.2018.07.23.18.02.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 23 Jul 2018 18:02:28 -0700 (PDT)
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, draft-mahesh-etsi-urn.all@ietf.org
From: Chris Lonvick <lonvick.ietf@gmail.com>
Message-ID: <5B567AA3.1010902@gmail.com>
Date: Mon, 23 Jul 2018 20:02:27 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------020400060008050500030703"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/l9tie0MFcc1U5__dZk925DelAd0>
Subject: [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 01:02:39 -0000

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.

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."

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 a__re generally_  described in Function_al_
    Requirements for_Uniform Resource Names_  [RFC1737 <https://tools.ietf.org/html/rfc1737>],_and_  Uniform Resource Names (URNs)
    [RFC8141 <https://tools.ietf.org/html/rfc8141>].


Best regards, Chris