[secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf

Chris Lonvick <lonvick.ietf@gmail.com> Fri, 05 September 2014 22:04 UTC

Return-Path: <lonvick.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B4C01A0299; Fri, 5 Sep 2014 15:04:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001] autolearn=ham
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 rZP887F8jzYL; Fri, 5 Sep 2014 15:04:26 -0700 (PDT)
Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6157C1A01A5; Fri, 5 Sep 2014 15:04:26 -0700 (PDT)
Received: by mail-pd0-f177.google.com with SMTP id r10so16613874pdi.36 for <multiple recipients>; Fri, 05 Sep 2014 15:04:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=CPZfOeermiVQ/bcKVPIU9Oow62r0VYGRUF9BtdFNiMY=; b=P9c5d8CrAnWSySzHJErsxcuV6Glym2ze0A2t2YJ59jrMuU6cadOzYuBxsel0GBPYQ5 mor5rUNY3UXzQPwusLw8nHL4QEwF9qzqq9a8qoZqIMhn9HubN/PxKzL4n1IFMHxNMoe1 XczxKFOkhZy7bmsVVr6X3j2S6EjjYbBPmdNDgqxlhINYk1sFPHLRn+HOPn6yZo/XwIeq H7CmABX0BR5e0ROVxpBNtLsoEf1arojgs8vL+zs0sfofkCFlOgURlns8x/G3qdEfu+ps o+42m29yg7Ec3LlhQwMtzdKhef2ptFLyGmCJuAK0mjTl0ppbeHPeJRKdBNKmhSJ+14z8 r0hg==
X-Received: by 10.70.34.136 with SMTP id z8mr26528027pdi.39.1409954666015; Fri, 05 Sep 2014 15:04:26 -0700 (PDT)
Received: from [192.168.1.76] (172-3-137-150.lightspeed.sntcca.sbcglobal.net. [172.3.137.150]) by mx.google.com with ESMTPSA id z3sm2529921pbt.84.2014.09.05.15.04.24 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Sep 2014 15:04:25 -0700 (PDT)
Message-ID: <540A3309.90802@gmail.com>
Date: Fri, 05 Sep 2014 15:02:49 -0700
From: Chris Lonvick <lonvick.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: iesg@ietf.org, secdir@ietf.org, draft-kyzivat-case-sensitive-abnf.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------040303060108000000020308"
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/BSLho3kTYSx4VemdVVMV_uzTQpM
Subject: [secdir] SECDIR review of draft-kyzivat-case-sensitive-abnf
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Sep 2014 22:04:28 -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 abstract is:

    This document extends the base definition of ABNF (Augmented Mackus-
    Naur Form) to include a way to specify ASCII string literals that are
    matched in a case-sensitive manner.


Overall, I don't like the statement in the Security Considerations 
section, but it is consistent with all other documents related to 
defining ABNF, and I can't find any noteworthy security issues anyway.  
 From that, I have no objection to moving this document forward.

I did find some nits and have some suggestions for improving readability.

1 - "Mackus-Naur" is used in two places rather than "Backus-Naur".

2 - The last sentence of section 2.1 is:

    This mechanism has a clear readability
    disadvantage, with respect to using a literal text string with a
    prefix, and new the prefix mechanism is preferred.


Perhaps you meant:
    This mechanism of using a literal text string with a prefix has a clear
    readability disadvantage.  The prefix mechanism described in this
    specification can be much more easily read.


3 - This part of Section 2.1 may be cleared up some:
  ---vvv---

If no prefix is present then the string is case-insensitive.

    Hence:

          rulename = %i"aBc"

    and:

          rulename = "abc"

    will both match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
    "ABC".


  ---^^^---

  Suggested:
   ---vvv---
      To be consistent with current implementations of ABNF, having no
      prefix means that the string is case-insensitive, and is equivalent
      to having the "%i" prefix.

    Hence:

          rulename = %i"aBc"

    and:

          rulename = "abc"

    are equivalent and both will match "abc", "Abc", "aBc", "abC", "ABc",
    "aBC", "AbC", and "ABC".
---^^^---

Best regards,
Chris