Re: [DNSOP] [ADD] Last Call: <draft-ietf-add-svcb-dns-05.txt> (Service Binding Mapping for DNS Servers) to Proposed Standard

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 27 June 2022 16:41 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556CAC15AAF1; Mon, 27 Jun 2022 09:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjmPmVyfhsie; Mon, 27 Jun 2022 09:41:48 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E01FC14F719; Mon, 27 Jun 2022 09:41:48 -0700 (PDT)
Received: by straasha.imrryr.org (Postfix, from userid 1001) id 31EC310021C; Mon, 27 Jun 2022 12:41:44 -0400 (EDT)
Date: Mon, 27 Jun 2022 12:41:44 -0400
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: dnsop@ietf.org, last-call@ietf.org, add@ietf.org
Message-ID: <YrndyP4u6mlF9lxd@straasha.imrryr.org>
Reply-To: dnsop@ietf.org
References: <165609154402.58404.11395433865653953448@ietfa.amsl.com> <1D0EA638-4B9E-4751-8321-54DBC4E0AC08@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1D0EA638-4B9E-4751-8321-54DBC4E0AC08@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/NeJOfLeqFi6v-o_VHaDusqyb5Dg>
Subject: Re: [DNSOP] [ADD] Last Call: <draft-ietf-add-svcb-dns-05.txt> (Service Binding Mapping for DNS Servers) to Proposed Standard
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2022 16:41:51 -0000

On Fri, Jun 24, 2022 at 05:31:28PM +0000, Eric Vyncke (evyncke) wrote:

> Dear DNSOP,
> 
> As this ADD WG document relies on draft-ietf-dnsop-svcb-https from the
> DNSOP WG, as the responsible AD for the ADD WG, I will appreciate your
> review of this short IETF draft.
> 
>     Abstract
> 
>        The SVCB DNS resource record type expresses a bound collection
>        of endpoint metadata, for use when establishing a connection to
>        a named service.  DNS itself can be such a service, when the
>        server is identified by a domain name.  This document provides
>        the SVCB mapping for named DNS servers, allowing them to
>        indicate support for encrypted transport protocols.

I have read the draft.  It aims to be agnostic as to whether the
DNS server that is the subject of the SVCB record is a recursive
resolver or an authoritative nameserver for some zone (typically
delegated by its parent).

It also aims to facilitate the establishment of an authenticated
transport.  It should be noted that with authoritative delegations from
a parent zone, the "service name" for each delegated to nameserver is
always obtained from the unsigned parent-side NS RRset.

Consequently unless the transport to the parent zone nameserver is
authenticated, there is an unavoidable MiTM exposure even when the zone
with the SVCB qname is DNSSEC-signed, because an on-path attacker can
tamper with the returned NS records.

And of course if the transport to the parent nameserver is not
encrypted, the name of the desired child zone is leaked in the clear,
defeating some or most of the privacy gains from subsequent use of an
encrypted transport with the child zone nameservers.

So perhaps the document should note using SVCB to signal transport
security for nameservers derived from NS records is predicated on a
suitably secure connection to the parent zone.

The use of SVCB RRs for authoritative nameservers introduces the
possibility that the SVCB target name is different from the "service
name" in the NS record.  Such additional indirection is perhaps
surprising or even undesirable.

Also, likely DoH would not be a supported transport for authoritative
servers, with DoT or DoQ being the available options.

If this draft is to be adopted for use with authoritative nameservers
these topics would warrant some further discussion, and perhaps some
minimal text is warranted to say as much.

-- 
    Viktor.