[core] Secdir telechat review of draft-ietf-core-resource-directory-25

Valery Smyslov via Datatracker <noreply@ietf.org> Mon, 10 August 2020 06:47 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: core@ietf.org
Delivered-To: core@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F357D3A141A; Sun, 9 Aug 2020 23:47:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Valery Smyslov via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: core@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <159704204394.11310.18005109400419971010@ietfa.amsl.com>
Reply-To: Valery Smyslov <valery@smyslov.net>
Date: Sun, 09 Aug 2020 23:47:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/lcZDyINKqzpl98wYScSo7KchpIg>
Subject: [core] Secdir telechat review of draft-ietf-core-resource-directory-25
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2020 06:47:24 -0000

Reviewer: Valery Smyslov
Review result: Ready

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.

The -24 version of this draft was reviewed by Adam Montville. I looked over his
review and I think that the issue he raised about possible  mitigation of DDoS
amplification attacks has been addressed in this version. I personally think
that sentences describing how DNS and NTP are vulnerable to amplification
attacks are redundant in this document, but that's a matter of taste and
doesn't hurt.

It is my impression, that Security Considerations were mostly written having in
mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or
even "MAY" if we look at RFC6690 which Security Considerations this draft
refers to). I think that adding a few words describing which consequences for
security not using (D)TLS would have and in which cases it is allowed will make
the Security Considerations more consistent.