[secdir] Secdir early review of draft-ietf-dance-architecture-06

Magnus Nyström via Datatracker <noreply@ietf.org> Wed, 24 July 2024 16:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from [10.244.2.81] (unknown [104.131.183.230]) by ietfa.amsl.com (Postfix) with ESMTP id B1BA3C207977; Wed, 24 Jul 2024 09:33:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Magnus Nyström via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.19.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172183882720.829011.13419227969664688355@dt-datatracker-659f84ff76-9wqgv>
Date: Wed, 24 Jul 2024 09:33:47 -0700
Message-ID-Hash: U2TNN7YDP5XSBS32JH3NXFKSVERM4SQI
X-Message-ID-Hash: U2TNN7YDP5XSBS32JH3NXFKSVERM4SQI
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-secdir.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dance@ietf.org, draft-ietf-dance-architecture.all@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: Magnus Nyström <magnusn@gmail.com>
Subject: [secdir] Secdir early review of draft-ietf-dance-architecture-06
List-Id: Security Area Directorate <secdir.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/lHux6MAzlngW2iNDsa565XBboLo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Owner: <mailto:secdir-owner@ietf.org>
List-Post: <mailto:secdir@ietf.org>
List-Subscribe: <mailto:secdir-join@ietf.org>
List-Unsubscribe: <mailto:secdir-leave@ietf.org>

Reviewer: Magnus Nyström
Review result: Not Ready

Like Ines Robles, I find this document not ready for publication, given several
open questions still remaining in the document itself, as well as, apparently,
externally recorded issues. As such, my review here is more an attempt to
provide feedback to the authors. - The approach is interesting but, to my
knowledge, similar attempts to leverage DNS has been proposed earlier (see
e.g., https://hal.science/hal-03798465/ - not sure if this document builds on
that work) and it could be interesting to compare with earlier proposals and
why this one would stand a better chance of succeeding. - As mentioned in the
document, requesting a TLS server to perform DNS lookup actions based on an
unauthenticated request seems prone to dDoS attacks, and it would be good if
the document could describe in some more detail how DANCE-enabled TLS servers
could protect against this. - The document touches on aspects of lifecycle
management for these certificates (e.g., "revocation is performed by simply
removing a DNS record,' or complexities when a device manufacturer no longer
supports or maintains the DNS entries). Would it make sense to have a fuller
discussion around lifecycle management of certificates in the context of DANCE?
I look forward to future revisions of this document.