[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.
- [secdir] Secdir last call review of draft-ietf-co… Adam Montville via Datatracker