[secdir] Secdir last call review of draft-ietf-add-svcb-dns-06

Joseph Salowey via Datatracker <noreply@ietf.org> Sat, 09 July 2022 00:05 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 9118CC15A758; Fri, 8 Jul 2022 17:05:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joseph Salowey via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: add@ietf.org, draft-ietf-add-svcb-dns.all@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.6.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <165732512858.37539.14391175135822397412@ietfa.amsl.com>
Reply-To: Joseph Salowey <joe@salowey.net>
Date: Fri, 08 Jul 2022 17:05:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/9cfqEuitk7vFbxjQ8AbvNfygs80>
Subject: [secdir] Secdir last call review of draft-ietf-add-svcb-dns-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 09 Jul 2022 00:05:28 -0000

Reviewer: Joseph Salowey
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 summary of the review is the document is ready.

A few comments:

- Section 8.1.2 - good description of this problem, it seems like some of this
should have been discussed in the doh document, but I couldn't find any.  If
there is relevant considerations in the doh document then you should reference
them here.  It seems that the recommendation "To mitigate redirection attacks,
a client of this SVCB mapping MUST NOT identify or authenticate itself when
performing DNS queries, except to servers that it specifically knows are not
vulnerable to such attacks." would be difficult to implement since its not
clear how the client gets this information and really should be a consideration
for the server implementations/deployments that require authentication.  I'm
not really sure what to do about this except as a consideration for a revision
of DoH.