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

David Mandelberg <david@mandelberg.org> Mon, 26 September 2016 00:49 UTC

Return-Path: <david@mandelberg.org>
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 D7AFA12B053 for <secdir@ietfa.amsl.com>; Sun, 25 Sep 2016 17:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 6LpPs6uQfeJV for <secdir@ietfa.amsl.com>; Sun, 25 Sep 2016 17:49:03 -0700 (PDT)
Received: from nm12-vm7.access.bullet.mail.bf1.yahoo.com (nm12-vm7.access.bullet.mail.bf1.yahoo.com [216.109.114.246]) (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 DECBA12B056 for <secdir@ietf.org>; Sun, 25 Sep 2016 17:49:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1474850940; bh=O1yhBOVefen4+xrnevMGGBgY2aKc1SeAjiu0ITuCmmw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From:Subject; b=F2MU4U80NWX2T7hNZ6qIz/kb1vphO1wUVq6R1HL2ou6YNjRhZxAU3B8IczsEr0NDJwJcfqvGB5xPmcA6wcARrAKg53iQTdDMFxxuSoFnP1Y1Q1jYdrt8hBOHLmwRnqoJBi55oGajJc8eFXUCXy7av/vFp0vR3NS2dgHuzdJZlhHJT4pC3TLb+rx9vtvimKVMmwZoe7/JMaeWBClN8sY98hvKg5teDZOY1XJUZuUUXShzR7hiSwwQnAoaTKN7YBFv913QM3mC1hhQ12auWD8OzXjzNIcNhujA41j/cy0zHkKbhki1hd57HnmY6VMfJxPluiAS+xg+vD3sdoLV2wTaxg==
Received: from [66.196.81.162] by nm12.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000
Received: from [98.138.226.243] by tm8.access.bullet.mail.bf1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000
Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 26 Sep 2016 00:49:00 -0000
X-Yahoo-Newman-Id: 213112.98160.bm@smtp114.sbc.mail.ne1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: U2Z162AVM1kRoWkesWE9dGOH3Evx_8IfHBMBCNcRNXvLbdI ZFK0_uKu2PYSOTI6x01xJq0QYyEni1wpjQ4Q3SRf8kc0bp5wYkDjeZke6HzN ndwQg8kJ3XnjGPDjE0yInpVfDx6ItqABt2WIVk9kPoEZN1IWU9JJkcqoh2C. uFKaTKlACYhtWYQ5rM48FmV29q74tbDB7WW_ox1qIXJepNBDSOHDaDE510jD G5SqXQq8UPjHofItjFXdNquv4V9k3GQS7gwY.4GEGqJJiJ70EgAKQaN2hhvV kFrXX.wzokz83F76K7F54mWFjxIJWfAZSeL7IjO2KLSZkVJg91WDGnz.epcL iETTucaw9IXUwPha7IkOE8uDMOJTh.JezVnixdyZjk5yYnibQHOhvjL7hcJp MKYmkdzj.AC_93inS5.ponXsRwoImIn7bURwlTgL60dIX3uc4oN0Zyrs7i3w NlVTizWTRiEW4AugKzMZdCQgadZjKuvTty.6e6wUiJ2ZtAKScued8DEsdt3e 7_6anwC2CRaW_tCdZrbgAGiJIIJfN4Q20BJOvt3UZGefRzEthKkn3zLSlH52 zFArCmbmBZJE-
X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708-
Received: from [192.168.1.153] (209-6-88-55.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com [209.6.88.55]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 759AB1C6033; Sun, 25 Sep 2016 20:48:58 -0400 (EDT)
To: Dino Farinacci <farinacci@gmail.com>
References: <17032e8e-f1d0-8fb4-7294-2e2ca5c9fb06@mandelberg.org> <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com>
From: David Mandelberg <david@mandelberg.org>
Message-ID: <cea887fa-f076-2ada-c9c8-fce548dccfca@mandelberg.org>
Date: Sun, 25 Sep 2016 20:48:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <2290972B-B93D-496A-8AF3-16B72D19B654@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2P0UCBpmuk3ITo188tCGwrlkK07SSfPuN"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/FAxvW56IL6dYAMG2K70Xb29Zbxs>
Cc: The IESG <iesg@ietf.org>, draft-ietf-lisp-lcaf.all@ietf.org, secdir@ietf.org
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: Mon, 26 Sep 2016 00:49:05 -0000

On 09/25/2016 06:15 PM, Dino Farinacci wrote:
>> 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?
> 
> No not for security purposes. There are multiple ways because we allow some nesting of information as well as allow for compatibility for older implementations that can’t parse some AFIs and LCAFs but is required to parse the AFI-List LCAF type.

Ok, then I think it needs to be made clear in the security
considerations that this format cannot be relied on to have no more than
one representation for the same information.

IESG: This means that I think this document is Ready With Nits.


>> 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.
> 
> Hmm, by definition, a mask-length of say 24 if a mask of 0xffffff00. And in 4.1:
> 
>   IID mask-len:  if the AFI is set to 0, then this format is not
>       encoding an extended EID-prefix but rather an instance-ID range
>       where the 'IID mask-len' indicates the number of high-order bits
>       used in the Instance ID field for the range.
> 
> It is clear that the high-order bits are used that cover the mask-length and the low-order bits are ignored. Is this not clear to you?

That part is clear to me. I just meant that the document as written
appears to allow 1.2.3.4/24 to be equivalent to 1.2.3.7/24. If the
format were going to be canonical, then all masked bits (the last octet
in this example) would need to be set to a well-known value (so,
1.2.3.0/24) instead of allowed to be anything.

> Would you want me to say the high-order bits are added with a mask and the bits not covered by the mask are set to 0?

If the format can't be relied on to be canonical, then my point is
irrelevant.


>> Section 5.4: There are many different ways to encode equivalent JSON
>> data here.
> 
> Maybe, but can you be more clear.

"{}" and "{ }" (note the space) are equivalent in JSON, but not
identical when compared byte-by-byte.

> I don’t think it is a bug. Do you?

As long as nobody relies on these to be canonical, it's not a bug.


>> 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.
> 
> In this respect “canonical” is relative to how LISP defines to encode both simple AFI encoded addresses or more complex/flexible addresses that accompany information.

Ok. I interpreted canonical to be a security property of the addresses,
i.e., that if two addresses are not bytewise equal, then they must not
have the same meaning. If that's not what you meant by canonical, then I
think the security considerations should say that, so that nobody tries
to rely on that property in the future.


>> 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.
> 
> I added some text to clarify this.

Thank you. The fields included in a key section were not the ones I
guessed, so the clarification was helpful. (Before your clarification, I
expected it to be everything from Rsvd3 through Key Material.)


>> 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.
> 
> We have put that in a use-case document. This Security Key LCAF is used by 2 use-cases. It is used for LISP-DDT and for lisp-crypto. In the lisp-crypto document we have a registry for cipher suites used.

Should this document reference one or both of those documents?


-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/