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

Donald Eastlake <d3e3e3@gmail.com> Thu, 02 March 2017 22:49 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 7564D128874; Thu, 2 Mar 2017 14:49:11 -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 YhzqPlgZ8yYC; Thu, 2 Mar 2017 14:49:10 -0800 (PST)
Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 1A989127601; Thu, 2 Mar 2017 14:49:10 -0800 (PST)
Received: by mail-it0-x231.google.com with SMTP id h10so2867792ith.1; Thu, 02 Mar 2017 14:49:10 -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=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=qxB9WRmnfYrI5JvjZNv49hTzhAstzzFSy2TdJ7PposkPB60INcOfwtnlbrw08xevzM d82oZpOgjs7LG5/+jO/MtM25LtOGGushEcmxDSv37TAnq+kZTOeRJa9ywFP7x/E2LKV6 s06QtWLYtiICv6ISFeKbJVZ4NY84a24ZEu4X0YH9S6V9U2YfW6YRhlddO+joeq4loSq7 3E5U5KSqTOPsDo1r5Eh2ZfC22SIm6nV7HpvbZFyjqDzVkd9yfgHs1qTahMOFQmNZncFw l9S/8A1/W1qghiIKALaEZnBxSzPHndAYJHOk4eXvRzqbw4lxUrFSn8e/qHRT2ot8DekJ +yRA==
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=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=erY/pFqmbkQgr6XBXUtI6E2GvnKbaMo0lj1n55Ike1unSBFyqAbe682FXmjNk8l602 AU2dCSqcl6phnXrgwWjV5kfsJkURKslESyNviq0sGY9lrIQt6BjCk2XKTXmDaYMKyFsw /8Tm4pWbfg72fEfjE+NpaX8gZ597RN7nTygcPvF/VB4eFkIDuYc3UpPv8My/MVjxzBpf fjWN2zvE59MmZiQXoreMHkYjz4HvEJbPPmJkmB5cyJhYj1qspex9b5a/podJkjiYtNPW Ms8qWlynops9vlZey6e9Npxc4ltSXCwai7J4XQNdUcp4fEGsd6vxQeLJLsP/zUtrypru FG5w==
X-Gm-Message-State: AMke39m+dHYKdakaHNubwGfu3aogNIA84jcqypnX0WxC4gpWT9ltY6DHDWH/NaUyIsbcO65sw0DKvwRmL9xJmw==
X-Received: by 10.36.3.73 with SMTP id e70mr195904ite.14.1488494949403; Thu, 02 Mar 2017 14:49:09 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:48:53 -0800 (PST)
In-Reply-To: <CAJm83bCdcDHomk3EJKEnbmdW6U22GGN5cyHPrdJC1H967v5OGw@mail.gmail.com>
References: <CAJm83bCdcDHomk3EJKEnbmdW6U22GGN5cyHPrdJC1H967v5OGw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 2 Mar 2017 17:48:53 -0500
Message-ID: <CAF4+nEEvHRpBO4JADBse7jb0gYU1TYeZ+mexg1K=BeBfkQgggQ@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/IK8MM0rXBNOeqo8qWHdgRpftlqI>
Cc: draft-ietf-trill-directory-assist-mechanisms-all@tools.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:49:11 -0000

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