[secdir] Secdir last call review of draft-ietf-core-resource-directory-24

Adam Montville via Datatracker <noreply@ietf.org> Tue, 24 March 2020 15:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A96DE3A0CCD; Tue, 24 Mar 2020 08:46:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Montville via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.122.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158506479161.11508.17361892799522117506@ietfa.amsl.com>
Reply-To: Adam Montville <adam.montville.sdo@gmail.com>
Date: Tue, 24 Mar 2020 08:46:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/sILowJEcUXs23I1N9l3KeTi6jN4>
Subject: [secdir] Secdir last call review of draft-ietf-core-resource-directory-24
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 24 Mar 2020 15:46:51 -0000

Reviewer: Adam Montville
Review result: Ready

I generally feel that this draft is ready. I do think the Security ADs should
pay particular attention to some of the security considerations. Most notable
is Section 8.3, Denial of Service Attacks. This section describes how a
Resource Directory (RD) “…can unknowingly become part of a DDoS amplification
attack,” but doesn’t provide any real mitigation or normative language toward
that end.

It is clear from the draft that the preferred deployment of these capabilities
is to leverage TLS or DTLS, but doing so is not mandatory per the draft. There
is an assumption, also, that clients are provided a certificate at the time of
manufacture, which can then be used by the RD as the endpoint’s name.

It seems that, with use of TLS/DTLS, and with certain device characteristics in
place, things are pretty well buttoned up. Without these assumptions, however,
it seems that the use of an RD could be problematic in more open deployments.
Then again, I’m not operating in the space of constrained devices day-to-day.