Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15

"Joel M. Halpern" <jmh@joelhalpern.com> Sat, 24 September 2016 19:11 UTC

Return-Path: <jmh@joelhalpern.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 1C35B12B01C; Sat, 24 Sep 2016 12:11:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 DqPDq4YoPJvp; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F18812B025; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 448431C5B87; Sat, 24 Sep 2016 12:11:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1474744310; bh=r7jR4Eo0KK8c9uaJcegv9cIey/7bhGzGIE+aBTCBT+Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=cUsKO8iRV8DRLCCzZfujKltI7e8L4Dpvg+Yw/g7V3c0NFDVg/BwMKd7kGBwvHLqLH Fxqh0tPchJiPbofdm4WmscwFIeU6052gGu4XzrZTZ07qDCLZs863BLBjtFoMgO/JFB 15pisZ7ZDnTeAOstxEMBEXu6yENn1SAEj/V9JDc0=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 927071C031A; Sat, 24 Sep 2016 12:11:49 -0700 (PDT)
To: David Mandelberg <david@mandelberg.org>, iesg@ietf.org, secdir@ietf.org, draft-ietf-lisp-lcaf.all@ietf.org
References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <28c0b4b6-c4b8-94a2-fc7c-629b66085b50@joelhalpern.com>
Date: Sat, 24 Sep 2016 15:13:15 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/viEHtDf98SrQ82w8IDqWtgb1FOs>
Subject: Re: [secdir] secdir review of draft-ietf-lisp-lcaf-15
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Sat, 24 Sep 2016 19:11:52 -0000

As I understand it, the multiple representations are deliberate.  I do 
think we should add a little text in the security considerations section 
noting that the representation has to be preserved if the information is 
signed.

Your comment on the algorithm ID in section 4.7 seems cogent.  I will 
let the authors respond.

On 9/24/16 2:53 PM, David Mandelberg 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.
>
> I found one issue in various parts of the document (described below),
> but I'm not sure it's relevant to security. If it is, then I think this
> document is Almost Ready. If not, then I think this document is Ready
> With Nits.
>
> There are multiple places in the document where it's possible to encode
> semantically equivalent information in multiple ways, despite the word
> "canonical" being in the title of the document. Is there anything that
> relies on these addresses being canonical for security purposes?
>
> Multiple places in the document (sections 4.1, 4.5, and 4.8) specify
> mask lengths, but do not specify that the masked out bits MUST be set to
> zero.
>
> Section 4.4: The description of RTR RLOC Address gives two different
> ways to encode an address with zero RTRs.
>
> Section 4.10.5: If I understand the compatibility mode correctly, this
> explicitly creates a second way to encode a semantically identical address.
>
> Section 5.4: There are many different ways to encode equivalent JSON
> data here.
>
> Section 6 (Security Considerations): There is no discussion of these
> addresses being canonical, and what other systems might or might not
> rely on these addresses being canonical.
>
>
> I also have some questions/nits:
>
> Section 3: Shouldn't the LCAF sort-key of {afi, LCAF-Type} also include
> the RLOC-address or LCAF payload?
>
> Section 4.3: Altitude is described as a signed integer, but this
> document doesn't specify the encoding. I assume it's two's complement,
> but that should probably be made explicit.
>
> Section 4.7: The Key Count description talks about "Key sections," but
> doesn't say which fields are part of the key section (and can thus be
> repeated). I have a guess which fields are part of the key section, but
> it's not entirely clear.
>
> Section 4.7: The Key Algorithm description doesn't point to a registry
> of valid values or otherwise say how to interpret values in that field.
>