Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms

Donald Eastlake <d3e3e3@gmail.com> Thu, 02 March 2017 22:57 UTC

Return-Path: <d3e3e3@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 C8FC412941A; Thu, 2 Mar 2017 14:57:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 qRo-itwZKwuk; Thu, 2 Mar 2017 14:57:20 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 5B54E128B37; Thu, 2 Mar 2017 14:57:17 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id 90so64105100ios.1; Thu, 02 Mar 2017 14:57:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPZZcbFfA5OPOx8ASN1wx7/bhSoNsLnEXnXNl9bE3os=; b=tGU79NZrEd3QQF51CwLfwCs5F7QZ3M277qR7vQzfRj8gA8SD6msUOW+YTLcl6643On nAb7SrIyW3iIEqBfEG3NZek324wHHHKNJyCwI45oQzysiRuEfYoA/TqJLHsJXP53UPbI fdvbQp6DsSy6gxTeSD8nU8iUFq9yjEITzlIb1Y1T2L5Vx8zPk/wYJHiajS9PL6hotgBE MseDR5ELSnnyPZoax8ug/9faLzoV7nSGXV82L97TSpvuqoa6GsdxvjM4pdZBD+2PWSVO +1589nbRJTmJA5dRYEPjfsShH3n3Us1f7Qa9FQBwuRa/92SoRnrWZpsJfJsgespl0prg PiXA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPZZcbFfA5OPOx8ASN1wx7/bhSoNsLnEXnXNl9bE3os=; b=FuGspYmt7eln/MkVzR3JjlgiN0+U3kbn+llMfWe7W/XpvZzq5wZVqUpdWJgXcgJysm sj3RCWYi0FNtOqjFWeO4brPJGirVL1KxgcrdyLQhI9Fy2mncj9bxJcXnQYjvupxymRjx cCpRZLXFy0vxKMLbr7Zxp2zAQIeMKUZ0HL4aVPIhgF1ZGmfG1MQXrXhoAJvGsthYyQ5o sFCricuVhKyyckgZmy1sL6dmgPUPU1SJaI8RWZFxulOdx3OYVq39ha917BmYj5BJ9cOd VuVU25t5mAR32yw5zyD0AEeCwEqtclHAB7GylNQlIFV9ovhBGfzcCdta3W+dG9u3uRD4 /m8g==
X-Gm-Message-State: AMke39nH78tkjVT0ZLyLWjCjxRCe7tRM2rIzIjOz5yrsfKVHby2RZuZFddFvGPJhucBW8WcRacPeJ10sDJbKmg==
X-Received: by 10.107.20.148 with SMTP id 142mr222682iou.12.1488495436665; Thu, 02 Mar 2017 14:57:16 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:57:01 -0800 (PST)
In-Reply-To: <CAF4+nEEvHRpBO4JADBse7jb0gYU1TYeZ+mexg1K=BeBfkQgggQ@mail.gmail.com>
References: <CAJm83bCdcDHomk3EJKEnbmdW6U22GGN5cyHPrdJC1H967v5OGw@mail.gmail.com> <CAF4+nEEvHRpBO4JADBse7jb0gYU1TYeZ+mexg1K=BeBfkQgggQ@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 2 Mar 2017 17:57:01 -0500
Message-ID: <CAF4+nEF25WMHiDgzKhfHYnEa8n_38SL-QWvyf7BUSpy8ZXux2Q@mail.gmail.com>
To: Daniel Franke <dfoxfranke@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/eRrmFNFl_4qNDQHKbetK8aOLYZs>
Cc: draft-ietf-trill-directory-assist-mechanisms.all@ietf.org, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms
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: Thu, 02 Mar 2017 22:57:22 -0000

Resending with draft-ietf-trill-directory-assist-mechanisms-all@tools.ietf.org
replaced with draft-ietf-trill-directory-assist-mechanisms.all@ietf.org.

On Thu, Mar 2, 2017 at 5:48 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
> Hi Daniel,
>
> Thanks for your comments. See below.
>
> On Tue, Jan 17, 2017 at 12:52 PM, Daniel Franke <dfoxfranke@gmail.com> wrote:
>> 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 believe this document is READY WITH NITS. I'm satisfied with its
>> normative content but the Security Considerations section could use
>> a bit of elaboration.
>
> OK.
>
>> I had never heard of TRILL prior to being assigned this review and
>> the tree of normative references is a bit daunting, so these comments
>> will necessarily be based only on an extremely high-level view of
>> the system.
>>
>> draft-ietf-trill-directory-assist-mechanisms proposes to augment
>> TRILL by adding directory servers which cache information about network
>> topology, allowing RBridges to sometimes shortcut the usual learning
>> algorithm that they would use to discover this information.
>>
>> Here are the fundamental points which the Security Considerations
>> section either addresses or ought to address:
>>
>> 1. There are three relevant security goals:
>>
>>    a. Availability: packets should reach their intended destination
>>
>>    b. Confidentiality: packets should not reach unintended destinations
>>
>>    c. Privacy: metadata concerning network presence should not be
>>       shared more widely than necessary
>>
>> 2. Access control to directory servers can be enforced using
>>    pre-existing cryptographic mechanisms specified in RFCs 5304, 5310,
>>    and 7978.
>
> Well, actually access to directory server messages.
>
>> 3. Principals authorized (duly or otherwise) to read directory data
>>    can violate privacy.
>
> OK.
>
>> 4. Principals authorized to modify directory data can violate
>>    availability and confidentiality.
>
> OK.
>
>> 5. Directory servers must therefore take care to implement and enforce
>>    access control policies which are not overly permissive.
>>
>> The current text of the Security Considerations section directly
>> addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of
>> the draft obliquely implies points 1c and 3 but I wish they'd be
>> stated more explicitly. But the major omission is point 5: what does
>> a correct authorization predicate look like? What sort of access must
>> necessarily be authorized in order for protocol execution to succeed?
>> What sort of access generally ought *not* be authorized?
>
> The -12 version just posted is intended to resolve these comments.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  d3e3e3@gmail.com