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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: dns-privacy <[e-mail]> On Behalf Of Tony Finch
> Sent: Wednesday, November 11, 2020 2:07 PM
> To: [e-mail]
> Subject: [EXTERNAL] [dns-privacy] how can we ADoT?
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> 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.
>
>
> ## 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.

It's not an EPP limitation. We can always define an EPP extension to add 
information to the parent zone. The issue is if the zone administrator 
can/will publish that information in the zone and if EPP clients are able and 
willing to provide it.

Scott