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

Christian Amsüss <christian@amsuess.com> Tue, 03 November 2020 17:23 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA26C3A0DFF; Tue, 3 Nov 2020 09:23:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 IFiboYpStJcd; Tue, 3 Nov 2020 09:23:02 -0800 (PST)
Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CF343A0DD5; Tue, 3 Nov 2020 09:22:44 -0800 (PST)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 464644082E; Tue, 3 Nov 2020 18:22:42 +0100 (CET)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 3E762AB; Tue, 3 Nov 2020 18:22:41 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:be1b:33a0:9df5:4f6f]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 0394C34; Tue, 3 Nov 2020 18:22:41 +0100 (CET)
Received: (nullmailer pid 52607 invoked by uid 1000); Tue, 03 Nov 2020 17:22:40 -0000
Date: Tue, 03 Nov 2020 18:22:40 +0100
From: Christian Amsüss <christian@amsuess.com>
To: Valery Smyslov <valery@smyslov.net>
Cc: secdir@ietf.org, draft-ietf-core-resource-directory.all@ietf.org, core@ietf.org, last-call@ietf.org
Message-ID: <20201103172240.GC45088@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="E13BgyNx05feLLmH"
Content-Disposition: inline
In-Reply-To: <159704204394.11310.18005109400419971010@ietfa.amsl.com> <20201103170958.GA45088@hephaistos.amsuess.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/5aQWg6Kgga2kx8PxXklSuDghWlc>
Subject: Re: [core] Secdir telechat review of draft-ietf-core-resource-directory-25
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Tue, 03 Nov 2020 17:23:05 -0000

(This is one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The various
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).

> 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.

response:

We've taken the comment as an opportunity to cut back on the history lesson
(change in https://github.com/core-wg/resource-directory/pull/249).

> 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. 

response:

Which level of protection is adaequate depends on the security policies. The
text you refer to was missed in updates, and now reflects that some security
mechanism ((D)TLS or OSCORE) SHOULD be used where the policies in place
indicate sensitive data. (See
https://github.com/core-wg/resource-directory/pull/250 for the full change).