[secdir] Secdir review of draft-ietf-6man-uri-zoneid-05

Radia Perlman <radiaperlman@gmail.com> Fri, 23 November 2012 06:29 UTC

Return-Path: <radiaperlman@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 AB4D721F8626; Thu, 22 Nov 2012 22:29:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.495
X-Spam-Level:
X-Spam-Status: No, score=-3.495 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id btGiCbwaLIrH; Thu, 22 Nov 2012 22:29:29 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 469F121F84C0; Thu, 22 Nov 2012 22:29:29 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so7431963vcb.31 for <multiple recipients>; Thu, 22 Nov 2012 22:29:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zKKAMsGXGTwjWQf1AO6WOqy5y3vYqfQLZJeSQgVAaLA=; b=YOrkUw+/C7DosyVIptq1o9d0fP3k10J++sF4yDCFTzPef6eEFQr95y4Gb1vjzEAiGX kUxjxc1778ZsTEdRHdOIvQvLGXAZxum64vvtETEeZHMdgnaMx2w+Qi7j5yUtB4zGU4FG I2ylwdR7QlG/bTr1YRD9uNYup+/7TUYmVqKRP+6X93I4UTKmcIiUNA0s/yf/Q0GJDwL/ 5UFcB/qfcqStBeqYxBWXc8rAwuiiKBYUFXOrFLrvys9R5A2CwNiwaxcSmkwOkqMUvQjh meSG9ovEZTYBNhE2rGNHlmoPjwHOFmg9gR/ewoYz4/MFKk51zxxrVg2/+cLRGfnwzIJo E2ag==
MIME-Version: 1.0
Received: by 10.59.13.197 with SMTP id fa5mr4565946ved.47.1353652168354; Thu, 22 Nov 2012 22:29:28 -0800 (PST)
Received: by 10.58.207.138 with HTTP; Thu, 22 Nov 2012 22:29:28 -0800 (PST)
Date: Thu, 22 Nov 2012 22:29:28 -0800
Message-ID: <CAFOuuo5SbxQL-mFx9MOmpFgRybTV0qcu7pXZTnvRE=3NVSh7xQ@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: The IESG <iesg@ietf.org>, secdir@ietf.org, draft-ietf-6man-uri-zoneid.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e0118499ca4e98904cf23b47c
Subject: [secdir] Secdir review of draft-ietf-6man-uri-zoneid-05
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, 23 Nov 2012 06:29:33 -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.

This document provides syntax for specifying a port within a URI for an
IPv6 link-local address.
I find no security-specific issues with this draft, but I do think the
clarity of the draft
could be improved a lot, and also, I think that the draft allows options of
what is or is not allowed,
which could cause confusion for a human using this, since some strings will
work sometimes.  I think it would
be better to lock down what is and is not allowed.

I'm not fond of the term "zone identifier" (I had to do some Internet
searching to figure out what it was). It would
only take a sentence to explain it in this draft.  Admittedly, not many
people will be reading this draft out of
context (like me).

An example of where the wording is needlessly hard to read, and where I
think the rule should be a MUST:

" A <zone_id> SHOULD contain only ASCII characters classified
   in RFC 3986 <http://tools.ietf.org/html/rfc3986> as "unreserved", which
conveniently excludes "]" in order
   to simplify parsing."

That wording could mean that ] is reserved or it could mean that it is not
reserved.
Turns out (by referring to RFC 3986) "]" is actually reserved.
And also, with my preference for specifying mandatory behavior rather than
recommendation...
perhaps saying something like

" A <zone_id> MUST NOT contain ASCII characters classified
   in RFC 3986 <http://tools.ietf.org/html/rfc3986> as "reserved".  The
character  "]" is reserved, so MUST NOT
  be used in the zone ID.


---------
Again,
    "The rules in [RFC5952 <http://tools.ietf.org/html/rfc5952>] SHOULD be
applied in producing URIs."
Why not MUST be applied?

----------
"we recommend that URI parsers accept bare "%" signs...make it easy for a
user to copy and
paste a string..."

again, I'd think it would be better to specify what parsers MUST do, rather
than saying some parsers
can be more lenient, so that the same string will create the same behavior
regardless of the implementation
parsing it.

---------
similarly

"To limit this risk, implementations SHOULD NOT allow use of this
   format except for well-defined usages such as sending to link local
   addresses under prefix fe80::/10."

I'd think it would be better to say MUST NOT, and also, to specify what it
should
do if it receives such a thing.

Radia