Re: [dns-privacy] how can we ADoT?

[Eric Rescorla <[e-mail]>]

On Wed, Nov 11, 2020 at 11:07 AM Tony Finch <[e-mail]> wrote:

>   2. Signal in an EDNS [@?RFC6891] or DSO [@?RFC8490] option: the
>     resolver starts by connecting in the clear, and upgrades to an
>     encrypted connection if the authoritative server supports it.
>
>     This is vulnerable to downgrade attacks. The initial cleartext
>     connection adds latency, and would need to be specified carefully
>     to avoid privacy leaks.
>

It's worth noting that one could add an HSTS-like mechanism here. Given
that a lot of requests are probably return customers, this would likely
result in quite a lot of lift.

-Ekr




>  3. Signal in DNS records: the resolver makes extra queries during
>     iterative resolution to find out whether an authoritative server
>     supports encryption, before the resolver connects to it.
>
>     The extra queries add latency, though that can be mitigated by
>     querying concurrently, and by placing the new records on the
>     existing resolution path.
>
>     DNSSEC can provide authentication and downgrade protection.
>
> This specification takes the last option, since it is best for
> security and not too bad for performance.
>
>
> ## Where can nameserver encryption records go?
>
> Where can we put the new DNS records to signal that a nameserver
> supports encryption? There are a number of issues to consider:
>
>   1. Performance: we don't want the extra queries to slow down
>      resolution too much;
>
>   2. Scalability: is encryption configured per nameserver? per zone?
>
>   3. Authentication: DNSSEC does not protect delegation NS records or
>      glue address records;
>
>   4. DNS data model: we ought to re-use existing RRtypes according to
>      their intended purpose;
>
>   5. DNS extensibility: make use of well-oiled upgrade points and
>      avoid changes that have a track record of very slow deployment;
>
>   6. EPP compatibility: a zone's delegation is usually managed via the
>      Extensible Provisioning Protocol [@?RFC5730] [@?RFC5731]
>      [@?RFC5732] so any changes need to work with EPP.
>
> The following subsections discuss the possible locations, and explain
> why most of them have been rejected.
>
>
> ## In the reverse DNS?
>
> Given a nameserver's IP address, a resolver might make a query like
>
>         _853._tcp.1.2.0.192.in-addr.arpa.    TLSA?
>
> This possibility is rejected because:
>
>   * It would be very slow: after receiving a referral, a resolver
>     would have to iterate down the reverse DNS, instead of immediately
>     following the referral.
>
>   * At the moment the reverse DNS refers to the forward DNS for NS
>     records; this would also make the forward DNS refer to the reverse
>     DNS for TLSA records. Dependency loops are best avoided.
>
>   * It's often difficult to put arbitrary records in the reverse DNS.
>
>   * Encryption would apply to the server as a whole, whereas the
>     working group consensus is that it should be possible for
>     different zones on the same server to use encrypted and
>     unencrypted transports.
>
>
> ## A new kind of delegation?
>
> In theory, DNSSEC provides a way to update the DNS data model, along
> the lines of the way NSEC3 was introduced [@?RFC5155]. The rough idea
> is to introduce new DNSSEC algorithm types which indicate that a zone can
> include new types of records that need special validation logic.
> Existing validators will be able to resolve names in the zone, but
> will treat it as insecure.
>
> We might use this upgrade strategy to introduce new delegation records
> that indicate support for transport encryption. However, it would
> require a very long deployment timeline. It would also require a
> corresponding upgrade to EPP.
>
> This is much too difficult.
>
>
> ## Non-delegation records in the parent zone?
>
> Although it's extremely difficult to change which DNS records can
> appear at a delegation, in principle the parent zone could contain
> information about a delegation in a separate subdomain, like
>
>         zone.example.    NS    ns1.zone.example.
>         zone.example.    NS    ns2.zone.example.
>         _853._tcp.ns1.zone._dot.example.    TLSA (...)
>         _853._tcp.ns2.zone._dot.example.    TLSA (...)
>
> The `_dot` tag makes the TLSA records into authoritative data in the
> parent zone, rather than non-authoritative glue-like records. To
> improve performance, the parent zone's nameservers could include these
> records in referrals as additional data. The resolver could
> authenticate them with DNSSEC and immediately use an encrypted
> connection to the child zone's nameservers.
>
> Although this idea would be secure and fast and compatible with the
> DNS, it is incompatible with EPP, so it is not realistically
> deployable.
>
>
> ## New DS record algorithm?
>
> The basic idea is to introduce a special DNSSEC algorithm number that
> can be used in DS records to indicate support for encryption. This
> runs into a number of problems, ultimately because it's trying to
> abuse DS records for an unintended purpose.
>
>   * DS records are per-zone, whereas encryption support is per-server.
>     Support for incremental deployment would need a hack like having a
>     DS record per nameserver, with further hacks to make it possible
>     for humans to understand encryption DS records.
>
>   * DS records can be updated by the child zone's DNSSEC key manager
>     using CDS and/or CDNSKEY records [@?RFC8078]; CDS implementations
>     would need to be changed to avoid interfering with encryption DS
>     records.
>
>   * There is a similar problem with ensuring that these DS records can
>     be updated through EPP. There are registries that generate DS
>     records from DNSKEY records themselves, rather than using DS
>     records submitted by the zone owner, so these encryption DS
>     records would have to be specified as the hash of a special DNSKEY
>     record.
>
>   * Poor scalability: there are orders of magnitude more zones than
>     there are nameservers. If the encryption signal is per-zone like
>     this idea, then it requires orders of magnitude more work to
>     deploy.
>
>
> ## Special-use nameserver addresses?
>
> Could we abuse special IP addresses (such as a new special-use IPv6
> address block) to signal support for encryption? This terrible idea is
> listed for completeness; it's bad because:
>
>   * It will cause problems for resolvers and other software that
>     doesn't understand the special IP addresses and tries to use them
>     as normal IP addresses;
>
>   * Glue addresses are not authenticated by DNSSEC so it's vulnerable
>     to downgrade attacks if the connection to the parent zone's
>     nameserver is insecure.
>
>
> ## Authenticator in nameserver hostname?
>
> We might signal support for encryption is in the nameserver hostname
> itself, like [@?DNScurve]. There is room for more than 300 bits in a
> domain name label, which is enough space to pack an authenticator
> (such as a cryptographic hash of a certificate) into the hostname.
>
> This trick would be compatible with the existing DNS and EPP, and it
> avoids adding delays. But there are problems.
>
> This idea would involve specifying a label format with roughly the
> same functionality as a TLSA record.
>
> Nameserver hostnames appear both in the zone's apex NS RRset, which
> can be authenticated by DNSSEC, and in the delegation NS RRset, which
> is not authenticated. So referrals are vulnerable to
> encryption-stripping downgrade attacks if the connection to the parent
> zone's nameserver is insecure. A resolver can avoid downgrades by
> re-fetching and validating the zone's nameservers from signed
> authoritative data below the zone cut, at the cost of exposing the zone
> name to snoopw, and a round-trip query delay.
>
> But the showstopper is its horrible scalability, even worse than the
> DS record idea described above: every zone's delegation and apex NS
> RRsets need to be updated to support encryption, and changed whenever
> a nameserver's key changes. Nameserver operators and zone owners are
> often different people, so key changes would require communication
> across multiple organization boundaries. Normal DNSSEC DS record
> updates involve the zone owner, primary server operator, and
> registrar; this idea involves all of them plus the secondary server
> operators.
>
>
> ## TLSA records alongside nameserver addresses
>
> This idea is to use TLSA records in a straightforward way:
>
>         ns1.zone.example.    A     192.0.2.1
>         ns1.zone.example.    AAAA  2001:db8::1
>         _853._tcp.ns1.zone.example.    TLSA    ( ... )
>
> The TLSA records only appear in the zone's authoritative data, so
> there are no delegation-related complications. They are signed with
> DNSSEC, which protects against downgrade attacks.
>
> It does not add any significant delay compared to a resolver that
> validates nameserver addresses: when the resolver queries for the
> nameserver's A and AAAA records, and the nameserver's zone's DNSKEY
> records, it can also concurrently request the nameserver's TLSA
> records.
>
> There is a clear framework for supporting other transports such as
> QUIC, by adding more TLSA records. (With the caveat that each new
> transport requires another query because the TLSA owner name varies
> per transport.)
>
> The main problem with this setup is that it needs something like glue:
> in many cases a resolver will need to know a nameserver's TLSA records
> in order to securely fetch the nameserver's TLSA records.
>
>
> ## Glue and nameserver TLSA records
>
> The DNS needs glue addresses when a resolver follows a referral to a
> zone whose nameservers are under the zone cut ([@!RFC1034] section
> 4.2.1). When the resolver wants to make an encrypted connection to
> these nameservers, it also needs the TLSA records, which are also
> under the zone cut.
>
> The resolver can make an unencrypted query for the TLSA records, then
> upgrade to an encrypted connection. This leaks the zone name to
> on-path passive attackers. The extra query is also slower.
>
> This might be acceptable in limited circumstances: If the zone
> containing the nameserver records is not used for other purposes, then
> a passive snoop already knows the zone name from the IP address of the
> nameserver. Queries for other domains hosted on the same nameserver
> can remain private.
>
>
> ## Encryption hint in nameserver hostname
>
> Unlike embedding a complete authenticator in the nameserver hostname,
> this idea adds a tag such as `dot--` to indicate that the nameserver
> supports an encrypted transport. The nameserver's authenticators are
> published in TLSA records.
>
> This idea avoids scalability problems, because encryption hints are
> only needed for nameservers that require glue ([@!RFC1034] section
> 4.2.1) and which cannot tolerate the privacy leak and delay that occur
> when a resolver upgrades to an encrypted connection after fetching a
> nameserver's TLSA records. Most zones can continue use the same
> nameserver hostnames they use now, without `dot--` tags, as discussed
> in (#hints).
>
> Encryption hints are vulnerable to downgrade attacks if the connection
> to the parent zone's nameserver is insecure. A resolver can avoid
> being completely downgraded using the procedure described in the
> previous subsection, but a downgrade attack can still force the
> resolver to leak the zone name.
>
>
> Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Trafalgar: In southeast, easterly 4 to 6. In northwest, southwesterly 5 to
> 7,
> becoming cyclonic 4 or 5 later. In southeast, moderate. in northwest,
> moderate
> becoming rough. In southeast, fair. In northwest, showers. Good.
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>