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

[Brian Dickson <[e-mail]>]

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

> I haven't seen anything written down that explains why it is difficult to
> do DoT to authoritative servers. There was a good discussion earlier this
> year about draft-vandijk-dprive-ds-dot-signal-and-pin which covered some
> of the issues. I have done a braindump that attempts to cover all the
> angles reasonably systematically. I expect I haven't quite reached that
> goal though, so I hope this will provoke some informative comments :-)
> Since draft submission is closed, I'll paste it here for your delectation.
>
>
> ## Explicit encryption support signal
>
> How can a resolver know an authoritative server supports encryption?
> There are three basic alternatives:
>
>  1. No explicit signal: the resolver tries to make an encrypted
>     connection, and falls back to cleartext if it gets an ICMP
>     unreachable error or connection timeout.
>
>     This is problematic because connection timeouts can be very slow,
>     especially if the resolver tries multiple encrypted transports.
>     This is also is vulnerable to downgrade attacks.
>
>     The working group consensus is that an explicit signal is
>     required.
>
>  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.
>
>  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.
>

Agree strongly, for the reasons you mention.


>
>
> ## 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?
>

Also:
Per (anycast) instance/location?
Per operator?
Per tuple (for whatever N-tuple of factors makes sense, like (zone,
operator, location, nameserver)?


>
>   3. Authentication: DNSSEC does not protect delegation NS records or
>      glue address records;
>

At worst that allows MITM observation, and perhaps DOS, but cannot invalide
the authentication itself otherwise.


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

It is also (grossly) non-scalable, particularly if/when any large-scale
change on delegations, or certificate rollovers/revocation/whatever.


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

This is only the case if the nameserver name itself is in need of privacy
protection.
One level of indirection can solve that, by using an additional domain for
the name servers for the aforementioned zone with nameserver names.
I.e. zone.example NS ns1.zone2.example etc.

The only strict requirement is that the chain of names/delegations all be
DNSSEC signed, IMHO.


>
>
> ## 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.
>
>
Plus caching FTW, the only time there is a cost is when a cache is cold.
The cost is amortized over the population of zones vs nameserver names.


>
> ## 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.
>
>
I'll add another section regarding the ability to distinguish which
nameservers support TLS...
## Multiple names for the same name server

By taking advantage of the indirection already present, i.e. domain NS
nameserver-name, plus nameserver-name A/AAAA address,
it is possible to have multiple names that point to the same address.
The purpose of having multiple names, is that it allows differentiation of
whether ADoT is supported via TLSA records being present/absent.
It avoids the need for any naming convention regarding the names
themselves, while allowing each operator to potentially use such naming
conventions for their own convenience.

Example names pointing to the same address:
DNS Provider 1:
adot-ns1.example.net A w.x.y.z
no-adot-ns1.example.net A w.x.y.z
_853._tcp.adot-ns1.example.net TLSA 3 x x ...

DNS Provider 2:
ns1.i-do-adot.example2.net A m.n.o.p
ns1.example2.net A m.n.o.p
*.i-do-adot.example2.net TLSA 2 x x ...

Zone with ADoT provided
example.com NS adot-ns1.example.net
example.com NS ns1.i-do-adot.example2.net

Zone with no ADoT, exact same set of name servers
example3.com NS ns1.example.net
example3.com NS ns1.example2.net

The differentiation of ADoT vs not is optional, not mandatory.
Some providers may choose to not do any ADoT, and not need to make any
changes at all.
Some providers may choose to do ADoT universally, and would only need to
add appropriate TLSA records, with no other changes needed.
Selective ADoT deployment would require adding at most N records in the
zone serving the names of their name servers (given an existing number N of
A/AAAA records), plus at most N TLSA records (or a wildcard TLSA record).
The migration of zones to such a differentiated provider would require EPP
updates for the migrated zones to change NS records, but would have no
further impact on resolution or zone maintenance going forward.
In particular there would not be a per-zone dependency on TLSA record
changes, and no requirement for any zone other than the nameserver names'
zone(s) to be DNSSEC signed.

Brian