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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
