Clarify how SNI and authentication works

draft-dnsop-deleg-dnssec.md

@@ -188,7 +188,7 @@ DNSSEC chain of trust provided by the "sharedds" parameter will be taken into ac
 # DNSSEC and DELEG {#dnssec}
 
 TODO: Should DS at parent serve as fallback if the SVCB does not have sharedds=? What if there is DS at the parent side and sharedds= in the SVCB?
-If there are any DS records on the same name as a DELEG record, ... 
+If there are any DS records on the same name as a DELEG record, ...
 
 When using the "sharedds" SvcParamKey, each DELEG record MAY indicate different DS contents.  This allows delegation of a zone to multiple signers with different DNSKEYs, and allows those configurations to change independently.  Note that a zone is only as secure as its least secure "sharedds" SvcParam.
 

draft-dnsop-deleg-transport.md

@@ -104,13 +104,13 @@ contributor:
 
 --- abstract
 
-This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in {{?I-D.draft-dnsop-deleg}}, with ability to specify transport protocols and authentication parameters supported by name servers.
+This document extends DELEG record, and SVCB records pointed to by DELEG record, as defined in {{!I-D.dnsop-deleg}}, with ability to specify transport protocols and authentication parameters supported by name servers.
 
 --- middle
 
 # Introduction
 
-The new delegation mechanism based on DELEG record type allows to specify attributes a resolver can use when talking to a delegated authority. This document introduces parameters specific to different transport mechanism than the default udp/53 protocol.
+The new delegation mechanism based on DELEG record type allows to specify attributes a resolver can use when talking to a delegated authority. This document introduces parameters specific to different transport mechanism than the default udp/53 protocol.  Transport selection and configuration follows the SVCB mapping for DNS {{!RFC9461}}, with some modifications described in this document.
 
 Legacy DNS resolvers unaware of DELEG mechanism would continue to use the NS and DS records, while resolvers that understand DELEG and its associated parameters can efficiently switch to new transports.
 
@@ -124,8 +124,8 @@ all capitals, as shown here.
 
 Terminology regarding the Domain Name System comes from {{?BCP219}}, with addition terms defined here:
 
-* [tbd]
-* [tbd]
+* (tbd)
+* (tbd)
 
 ## Introductory Examples
 
@@ -163,60 +163,95 @@ Later sections of this document will go into more detail on the resolution proce
 
 The primary goal of transport specification in DELEG records is to provide zone owners a way to signal to new clients how to connect to servers serving a child domain that can coexist with NS records in the same zone, and do not break software that does not support new transports.
 
-### SvcParams
+# Use of SvcParams
 
-All SvcParamKeys for the "dns" scheme {{?9461}} apply as specified.  These are the "transport parameters", describing how to reach an endpoint.
+All SvcParamKeys for the "dns" scheme {{!RFC9461}} apply as specified.  These are the "transport parameters", describing how to reach an endpoint.
 
 The "alpn" transport parameter is OPTIONAL to include (unlike in SVCB-DNS, where it is generally required).  If the "alpn" SvcParamKey is omitted, the only available transport is presumed to be unencrypted DNS over UDP/TCP port 53.  Endpoints can indicate that insecure transport is not available by specifying "mandatory=alpn".
 
 When TargetName is below the zone cut, DELEG ServiceMode records MUST include "ipv4hint" or "ipv6hint" SvcParamKeys.  These keys provide the address glue, which enables the initial connection to this endpoint.
 
-The following additional DNS SVCB parameters are defined for the DELEG and SVCB ServiceModes.
+## New transport parameter: "tlsa"
 
-#### "tlsa"
+The "tlsa" SvcParamKey is a transport parameter representing a TLSA RRset {{?RFC6698}} to be used when connecting to TargetName using a TLS-based transport. If present, this SvcParam MUST contain all the TLSA records whose owner name ({{?RFC6698, Section 3}}) can be inferred from TargetName and the other SvcParams (e.g., "alpn", "port"). Like "ipv4hint"/"ipv6hint", this SvcParam serves two purposes in DELEG:
 
-The "tlsa" SvcParamKey is a transport parameter representing a TLSA RRset {{?RFC6698}} to be used when connecting to TargetName using a TLS-based transport. If present, this SvcParam SHOULD match the TLSA records whose base domain ({{?RFC6698, Section 3}}) is TargetName. Due to bootstrapping concerns, this SvcParamKey has been added to the DELEG record as the TLSA records might only be resolveable after the initial connection to the delegated nameserver was established. When this field is not present, certificate validation should be performed by either DANE or by traditional TLS certification validation using trusted root certification authorities.
+* When resolution of the TLSA records would encounter a cyclic dependency, the "tlsa" SvcParam MUST be included.
+* Otherwise, the TLSA query cannot generally be performed until after the SvcParams are received, potentially delaying connection establishment.  The "tlsa" SvcParam might save time in this case.
 
-The SvcParamValue is a non-empty value-list.  The presentation and wire format of each value is the same as the presentation and wire format described for the TLSA record as defined in {{?RFC6698}}, sections 2.1 and 2.2 respectively.  To avoid wasting resources in the parent zone, parents MAY reject RRSets containing "tlsa" SvcParams that use matching type 0 (exact match).
+When this SvcParam is not present, certificate validation MAY be performed either using DANE (if TLSA records are present) or by PKI-based TLS certification validation using trusted root certification authorities.
 
-As a special case, the presentation value "disabled", corresponding to an empty value in wire format, indicates that DANE MUST NOT be used with this record.
+The SvcParamValue is a non-empty value-list.  The presentation and wire format of each value is the same as the presentation and wire format described for the TLSA record as defined in {{?RFC6698}}, sections 2.1 and 2.2 respectively.  To avoid wasting space in the parent zone, parents MAY reject RRsets containing "tlsa" SvcParams that use matching type 0 (exact match).
 
-To avoid a circular dependency, "tlsa" MUST appear in any DELEG record that is used to serve its own TargetName.
+As a special case, the presentation values "enabled" and "disabled" correspond to a single octet value of 1 and 0 in wire format.  A value of "enabled" indicates that TLSA records exist but are not embedded in this record and must be queried directly.  A value of "disabled" indicates that TLSA records do not exist, and DANE MUST NOT be used with this record.  A value of "enabled" SHOULD be accompanied by "mandatory=tlsa", while a value of "disabled" SHOULD NOT.  A value of "enabled" MUST NOT be used when the nameserver serves its own TargetName, as this creates a circular dependency.
 
 Resolvers that support TLS-based transports MUST adopt one of the following behaviors:
 
 1. Use DANE for authentication, and treat any endpoints lacking DANE support as incompatible.
-1. Use PKI for authentication, and treat any DANE-only endpoint as incompatible.  In this behavior, compatibility with `tlsa=disabled` endpoints is REQUIRED.
+1. Use PKI for authentication, and treat any DANE-only endpoint as incompatible.
 1. Support both DANE and PKI for authentication, preferring DANE if it is available for each endpoint.
 
+When a DANE-capable resolver encounters a DELEG or SVCB record containing TLSA RDATA, it MUST NOT perform any TLSA queries or make use of any TLSA record's RDATA, as this indicates a potential cyclic dependency and using cached TLSA records would introduce unnecessary variability in behavior.
+
 This SvcParamKey MAY be used in any SVCB context where TLSA usage is defined.
 
+| SvcParams                            | DANE  | PKI |
+|--------------------------------------|-------|-----|
+| (no params)                          | No    | No  |
+| alpn=doq                             | Maybe | Yes |
+| alpn=doq tlsa=enabled                | Yes   | Yes |
+| alpn=doq tlsa="..."                  | Yes   | Yes |
+| alpn=doq tlsa=enabled mandatory=tlsa | Yes   | No  |
+| alpn=doq tlsa="..." mandatory=tlsa   | Yes   | No  |
+| alpn=doq tlsa=disabled               | No    | Yes |
+{: title="Representation of all combinations of DANE and PKI support"}
+
+# Identifying the Server
+
+In the SVCB mapping for DNS {{!RFC9461}}, the client is presumed to know an "authentication name" that is used to identify and authenticate the server in TLS.  When DANE is in use {{!I-D.ietf-dnsop-svcb-dane}}, the owner of the authentication name can use DNSSEC to authorize a different TLS server identity.  Otherwise, the DNS contents do not affect the authentication process, so the connection is secure even if DNS responses have been modified by an adversary.
+
+In DELEG, the client (a resolver) does not initially know an "authentication name" for any of the desired authoritative servers.  The resolver only knows the apex name of the child zone.  This name is not used as the authentication name.  Instead, the TargetName of each initial DELEG record serves as the initial authentication name for connections relying on that record.  The subsequent connection setup (and SVCB queries, if the DELEG record is in AliasMode) are performed in accordance with {{!RFC9461}} (and {{!I-D.ietf-dnsop-svcb-dane}} if the resolver supports DANE).
+
+If the initial DELEG record is resolved securely, this procedure is secure even if the child zone is not signed.  Otherwise, this procedure provides only opportunistic security, because an attacker could have replaced the DELEG record with one that authorizes the attacker's certificate.
+
+## Examples
+
+~~~Zone
+example.com. DELEG 1 ns2.example.com. (
+                alpn=dot
+                tlsa="3 0 1 ABC..."
+                ipv4hint=192.0.2.54
+                ipv6hint=2001:db8:2423::3 )
+~~~
+{: title="SNI is 'ns2.example.com'"}
+
+~~~Zone
+example.com. DELEG 0 ns-1234.operator.example.
+
+;; The operator.example. zone is presumed to be signed.
+ns-1234.operator.example.          SVCB 1 x1234.opshost.example. alpn=dot
+
+;; The opshost.example. zone is also presumed to be signed.
+_853._tcp.x1234.opshost.example. TLSA 2 0 1 ABC...
 ~~~
-;; The server is only authenticatable via DANE.  Any resolver that
-;; lacks DANE support will treat this record as incompatible.
-alpn=doq tlsa="..." mandatory=alpn
-
-;; The server is only authenticatable via DANE, but also offers Do53
-;; services.  All resolvers can access it, but only resolvers with
-;; DANE support will use DoQ.
-alpn=doq tlsa="..."
-
-;; The server is authenticatable via PKI.  If TLSA records exist at
-;; the SVCB-DANE owner names, it is also authenticatable via DANE.
-;; This record cannot be used to serve the zone containing its TargetName.
-alpn=doq
-
-;; The server is only authenticatable via PKI.  Any resolver that
-;; lacks PKI validation support will treat this record as incompatible.
-alpn=doq tlsa=disabled mandatory=alpn
+{: title="SNI is 'x1234.opshost.example' if the resolver supports DANE, otherwise 'ns-1234.operator.example'"}
+
+~~~Zone
+example.com. DELEG 1 ns-v4.example.com. (
+                alpn=dot
+                tlsa="3 ..."
+                ipv4hint=192.0.2.54 )
+example.com. DELEG 1 ns-v6.example.com. (
+                alpn=dot
+                tlsa="3 ..."
+                ipv6hint=2001:db8:2423::3 )
 ~~~
-{: title="tlsa SvcParam Examples for DELEG"}
+{: title="SNI is 'ns-v4.example.com' for IPv4, and 'ns-v6.example.com' for IPv6"}
 
-## Deployment Considerations
+# Deployment Considerations
 
 The DELEG and SVCB records intends to replace the NS record while also adding additional functionality in order to support additional transports for the DNS. Below are discussions of considerations for deployment.
 
-### Availability
+## Availability
 
 If a zone operator removes all NS records before DELEG and SVCB records are implemented by all clients, the availability of their zones will be impacted for the clients that are using non-supporting resolvers. In some cases, this may be a desired quality, but should be noted by zone owners and operators.
 

draft-dnsop-deleg.md

@@ -247,6 +247,8 @@ The TargetName of an SVCB or DELEG record MAY be the owner of a CNAME record. Re
 
 Special care should be taken by both the zone owner and the delegated zone operator to ensure that a lookup loop is not created by having two AliasMode records rely on each other to serve the zone. Doing so may result in a resolution loop, and likely a denial of service. The mechanism on following CNAME and SVCB alias above should prevent exhaustion of server resources. If a resolution can not be found after 4 lookups the server should reply with a SERVFAIL error code.
 
+If queries for a DELEG or SVCB ServiceMode record's TargetName would have a cyclic dependency on this RRset, this record MUST include at least one "ipv4hint" or "ipv6hint" SvcParam.  If either of these SvcParams is present in a DELEG or SVCB ServiceMode record, the resolver MUST only use IP addresses from these SvcParams when making use of this record, as their presence indicates a potential cyclic dependency and using cached A/AAAA records would introduce unnecessary variability in behavior.
+
 ## Deployment Considerations
 
 The DELEG and SVCB records intends to replace the NS record while also adding additional functionality in order to support additional transports for the DNS. Below are discussions of considerations for deployment.