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

Ben Schwartz <bemasc@google.com> Mon, 27 June 2022 18:29 UTC

Return-Path: <bemasc@google.com>
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 4A7EBC15A723 for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 11:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.609
X-Spam-Level:
X-Spam-Status: No, score=-17.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 IAILOSjoHkWQ for <dnsop@ietfa.amsl.com>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 B025BC14F741 for <dnsop@ietf.org>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
Received: by mail-vk1-xa2c.google.com with SMTP id h26so4866192vkc.2 for <dnsop@ietf.org>; Mon, 27 Jun 2022 11:29:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rKrbWwOvWMXlyi6zhY0IO4KadHJ7bkrsS7XQ9dln8fo=; b=LM+loT62jy5fdLB7+LaqYzp9wcbIqtfFfRkZk/Z266BDRHP/of+IOtRkmYWXmHkxWC nERaMOT4gUNcFNSS3UweC6zGz8rNnKJ6j4rUGgWRFVsjVJZJ9xDjfUoj9RrKBD0Sfi6v Tag7dN5lqmWecW+/VRFl1UI2wkYyBMBTC1eHA3D27fYXbyx1whSk63eFS8wT52zmP3f9 F/wF8bs3RjSd10S+V5S8wc4NLy+7LJSA9tW9ors1VM9CzB/TsoLRVIxiAeX02rDX/8hB QUSuY0CzY2+np+9x6m9Y92o+JuRFZd7mcAwq4+YolFLCLU51bL9yEtKuh/GgTvpplLc6 aXxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rKrbWwOvWMXlyi6zhY0IO4KadHJ7bkrsS7XQ9dln8fo=; b=n/7cJ1711VEdXIvjaOH9E+RETOO7wLjhsNuYUWM2xdQ7LsSDNP846lRQcsLYDrBzkX 5kHxiEyFghyKItbLx6del+JBNOGQ7LiuMyGX6eu51kB16+gKD5VBNWyf4bt4b97JkQlH w/r+Zb+v/gJ6Png8W3kc255dgSJiwTCfSmhQ2Xt2a+6mEh/Sa6Uy3VfmgaABpCuW4hC3 mEPxQAIcdlcfIeNT0nGf0LUFt5RTLabVQFIDZIsfQtcSU/sVvR2qhJL4dtxZ3UQUaCnx FLqiurtFHR91AXsltTRUyYy+fgIdhhRrOXJFw/RImCoa7gjQUb2PzLDmxSK9/kDmQfeH V4mw==
X-Gm-Message-State: AJIora8myCz1mh/4lOXB5Wnjf1HDYEAfc4iE+He+QKoXrD+3U4EVgtFa 3V5TrlHF/JubONxlQwqswBHXgWbzthKR8Qb7ID0OrOi5ryvL9w==
X-Google-Smtp-Source: AGRyM1u2FhafIkxdH+c/SWdiuTdtc+QgAxAvGiiifBnApQcHefh1ZEdn9PkMN+t7AV/6lwCVvXf74TLFWbvUNYtrBrs=
X-Received: by 2002:ac5:c7c7:0:b0:36c:5b47:f01a with SMTP id e7-20020ac5c7c7000000b0036c5b47f01amr291469vkn.39.1656354539448; Mon, 27 Jun 2022 11:28:59 -0700 (PDT)
MIME-Version: 1.0
References: <165609154402.58404.11395433865653953448@ietfa.amsl.com> <1D0EA638-4B9E-4751-8321-54DBC4E0AC08@cisco.com> <YrndyP4u6mlF9lxd@straasha.imrryr.org>
In-Reply-To: <YrndyP4u6mlF9lxd@straasha.imrryr.org>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 27 Jun 2022 14:28:48 -0400
Message-ID: <CAHbrMsAPdsT57zvVChzZvpo7=pFt41j9+yYmB67VcAT7_OF2_A@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Cc: last-call@ietf.org, ADD Mailing list <add@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000f860a005e272173d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9tg6CjZ5g6OdNDhm7XfPCoiVJ4Y>
Subject: Re: [DNSOP] [Add] [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 18:29:01 -0000

On Mon, Jun 27, 2022 at 12:43 PM Viktor Dukhovni <ietf-dane@dukhovni.org>
wrote:
...

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


Hi Viktor,

I think these are points worth mentioning, and I've written up some
proposed text that would remind the reader about them [1].  Please review.
I've tried to address these topics without focusing too heavily on the
"authoritative nameserver" point because I think they actually have broad
applicability.

--Ben

[1]
https://github.com/ietf-wg-add/draft-ietf-add-svcb-dns/pull/21/files?short_path=c64c01d#diff-c64c01dc53e1ad2566b406d021b17a713d5623b9bfda235eb78eed885ee58377