Merge pull request #4 from ekr/caw/clarifications

Attempts to clarify.

draft-rescorla-dprive-adox.md

@@ -27,18 +27,18 @@ author:
     organization: Mozilla
     email: ekr@rtfm.com
 
+ -
+    ins: D. Schinazi
+    name: David Schinazi
+    organization: Google LLC
+    email: dschinazi.ietf@gmail.com
+
  -
     ins: C. A. Wood
     name: Christopher A. Wood
     organization: Cloudflare
     email: caw@heapingbits.net
 
- -
-    ins: "D. Schinazi"
-    name: "David Schinazi"
-    organization: "Google LLC"
-    email: dschinazi.ietf@gmail.com
-
 
 
 normative:
@@ -74,7 +74,7 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 document are to be interpreted as described in BCP 14 {{RFC2119}} {{!RFC8174}}
 when, and only when, they appear in all capitals, as shown here.
 
-# Overview of Operation
+# Overview of Operation {#overview}
 
 The mechanism defined in this document works by using the DNS SVCB
 {{SVCB}} record to indicate that a given server supports TLS. The
@@ -104,16 +104,14 @@ A example.com? ------------------------------------------->
 ~~~~
 
 The recursive resolver starts by contacting the authoritative server
-for .com and asks for the NS records for example.com.
-[[OPEN ISSUE: Is this right?]]
-The
-authoritative returns the NS record pointing at ns.example.invalid and
-also returns a glue records for ns.example.invalid
-indicating that it supports DNS over
-TLS (DoT), in much the same way as it might have sent an
-IP address for that server.
-This additional record is the only difference from the
-current situation, and allows the recursive resolver to know that
+for .com and asks for the NS records for example.com. Note that .com
+is not authoritative for the example.com apex, and will not sign the
+NS RRset; see {{?RFC4035}}, Section 2.2, and {{security}} for details.
+The authoritative returns the NS record pointing at ns.example.invalid and
+also returns a glue records for ns.example.invalid indicating that it
+supports DNS over TLS (DoT), in much the same way as it might have sent an
+IP address for that server. This additional record is the only difference
+from the current situation, and allows the recursive resolver to know that
 it can reach ns.example.invalid over encrypted transport.
 
 
@@ -134,25 +132,29 @@ both TCP and QUIC).
 Upon determining that a given nameserver supports a compatible
 encrypted transport, an implementation MUST only use encrypted
 transport for the rest of the cache lifetime for that information
-and MUST hard fail with error [[TODO]] if it is unable to establish a connection.
+and MUST hard fail with error if it is unable to establish a connection.
 If multiple encrypted transports are available, an implementation
-SHOULD try all of them before declaring failure.
+SHOULD try all of them before declaring failure. An implementation
+MUST NOT consider an answer authentic unless it is either signed
+via DNSSEC or received over an encrypted transport.
 
+[[OPEN ISSUE: figure out error details]]
 
 ## Caching and lifetime
 
 Note that in the common case where the name of the target
 authoritative resolver is out-of-bailiwick {{?RFC7719}} for the
-referring resolver, then the SVCB record will likely not be retained
+referring resolver, then the SVCB record may not be retained
 for future queries. This can create a situation in which a given
 authoritative resolver will be queried over encrypted transport for
 one name and over unencrypted transport for another. This is not the
 end of the world (HTTPS has historically operated in this way, with
 the security properties being attached to the reference), but is also
 not ideal. In order to prevent this, resolvers which are also
-authoritative for their own name SHOULD send SVCB records back
-for themselves in the additional data section so that they can
-be properly cached.
+authoritative for their own name SHOULD send SVCB glue records
+in the additional data section so that they can be properly cached,
+and the TTL for these SVCB records SHOULD match that of the
+corresponding NS records in the same RRset.
 
 [[OPEN ISSUE: Do people cache out-of-bailiwick DNSSEC-signed records?]]
 [[OPEN ISSUE: How often is the case where ns.example.invalid is not
@@ -190,12 +192,12 @@ defined in {{?I-D.ietf-tls-dnssec-chain-extension}}.
 
 [[OPEN ISSUE: Resolve this.]]
 
-# Security Considerations
+# Security Considerations {#security}
 
 The primary security property delivered by this mechanism is
-confidentiality of the query and response. As long as (1) All queries
+confidentiality of the query and response. As long as (1) all queries
 in the resolution chain, including to the authoritative resolver are
-encrypted and (2) All resolvers in the resolution chain are
+encrypted and (2) all resolvers in the resolution chain are
 trustworthy, then even an on-path attacker cannot discover the
 name being resolved or its response. However, if either of these conditions
 is violated, then an attack is possible:
@@ -210,18 +212,24 @@ is violated, then an attack is possible:
 
 Note: DNSSEC signing might mitigate some these issues, but it is
 undesirable to have a system which depends on universal DNSSEC.
-[[TODO: Tommy, can you analyze this?. I think NS aren't signed
-so basically it's hopeless]]
-
-An on-path attacker does, however, likely learn the identity of
-the authoritative server; if that server only serves a small
-number of domains then the attacker will learn information
-about what is being resolved.
-
-As a secondary property, this mechanism can provide some level
-of integrity for DNS responses, again under the condition that
-each resolver in the chain is trustworthy. By contrast,
-DNSSEC provides integrity even if the resolvers are untrustworthy.
+Moreover, delegations at top-level zones are not signed, as
+per {{?RFC4035}}, Section 2.2. In practice, this means a recursive
+resolver attempting to resolve a zone apex query, such as example.com
+in {{overview}}, cannot assume the NS answer is authentic. However,
+given the number of top-level domain servers, resolvers may use an
+HSTS-like mechanism for determining whether which top-level servers
+support encrypted transports.
+
+Encryption does not mitigate all leakage. In some circumstances, an
+on-path attacker may learn the identity of the authoritative server if,
+for example, that server only serves a small number of domains. The
+attacker can learn information about what is being resolved by observing
+whether or not server is queried.
+
+As a secondary property, the mechanism in this document can provide some level
+of integrity for DNS responses, again under the condition that each resolver
+in the chain is trustworthy. By contrast, DNSSEC provides integrity even if
+the resolvers are untrustworthy.