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

Eric Rescorla <> Wed, 11 November 2020 19:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B7053A0FD6 for <>; Wed, 11 Nov 2020 11:50:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wFMEsG2lV7tR for <>; Wed, 11 Nov 2020 11:50:48 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30DED3A0FD0 for <>; Wed, 11 Nov 2020 11:50:48 -0800 (PST)
Received: by with SMTP id y16so3451405ljk.1 for <>; Wed, 11 Nov 2020 11:50:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iIEOpTihYBrYivOk/bZ6hyj+VUdtHTDOLlfoxr0VnRM=; b=emvlBUcTsbsxBBiaH4ZhUw2hazww3wjiJ2eWUo/y7Kjywq3AS4gSoMLLLDpb2693CG ZjCTZCNkbxGOmZpMVH+IBaxKKwbrt7cMiQQLDySza2VhawJ6L+myb5n8UggEOQulA7y3 W+xZTi1rEGed+rTGAiOqxfFfs9LTfme2G8aEOa2vcgKJrZPw+2G/SWs/NOWS3X0+xUqx wealdmxZEHBf0pNvKgFtKn/Zzx1U5nCOf2HYPhhaGFF+8uestoBDPwGfR2zqK9IaJk6b iwyAZ2yCd/ySGlxPiwEG/dKcn3e2KIE4dNC5if4UUALJGhg3OFgapxwSnNixG5ymFC7A F6rA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iIEOpTihYBrYivOk/bZ6hyj+VUdtHTDOLlfoxr0VnRM=; b=bEPIT3jTqq76fldhoQAdfxmv6fUNawowBmtDRAWJdyBXUUFfLeA1RWgyogRVuHD5R1 xEg1zN8hZgZfydP9z/cHwLn9wD8jysFdcM3xx2GpzibDlnJ3tIcXz+PrKp60Yg028sCK n3Vk53Xma6NfNHfHFIe/+5xbyoYK93gQwfwo9cgt/Z6zj1FBlZ6L59Y6NNXo9eFogIK4 KnA/GbDLiyLZd3VSk650sN5Ze9/WeGMLgv9VlttXdPGh37ZyuIDWvUEEh9nZ7pd+Kg1X Fb2W4oqk85ONH76TNfzokhg4JprL5kBkd/DEdn3WZvHu0ACFGvyqVKKvstLcKVGAWM+Q lMEA==
X-Gm-Message-State: AOAM53336Cif4ynbkcEg9hwziZ5JWvQKUkpbquvPFCoYbNaEwNMTKYug PJGxvKkuQ/HSLXWUz0qkVy88AXXpjutp8cT4fwaZpKzw3QHJ9g==
X-Google-Smtp-Source: ABdhPJxWrl2q4fKS+bh3E6aruN5rj16XcCjZ03McD+HBFnXSAmbCfJLZJ5A+/SjO4jXCOYI7mhKJrSITjz8Lm9DQDXg=
X-Received: by 2002:a05:651c:113b:: with SMTP id e27mr1537245ljo.17.1605124246395; Wed, 11 Nov 2020 11:50:46 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Eric Rescorla <>
Date: Wed, 11 Nov 2020 11:50:10 -0800
Message-ID: <>
To: Tony Finch <>
Cc: DNS Privacy Working Group <>
Content-Type: multipart/alternative; boundary="00000000000086fae505b3da1c8c"
Archived-At: <>
Subject: Re: [dns-privacy] how can we ADoT?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2020 19:50:52 -0000

On Wed, Nov 11, 2020 at 11:07 AM Tony Finch <> 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.


>  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
>    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
>         zone.example.    NS
>    TLSA (...)
>    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:
>    A
>    AAAA  2001:db8::1
>    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  <>
> 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