On Wed, Nov 11, 2020 at 11:07 AM Tony Finch <[email protected]> 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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
