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

Manu Bretelle <> Wed, 11 November 2020 20:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A86C3A10B9 for <>; Wed, 11 Nov 2020 12:32:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 AYeJv1WBFlcI for <>; Wed, 11 Nov 2020 12:32:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA71D3A10B7 for <>; Wed, 11 Nov 2020 12:32:44 -0800 (PST)
Received: by with SMTP id p10so3206850ile.3 for <>; Wed, 11 Nov 2020 12:32:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DOTbv7K25cYxpC5x/Br3T7yzKshJekunJ8qOG51LxBo=; b=NiZXXSKjp6KYcKP1NsmT8lZwEoOk8AKfCW92kxj/1c76HDGhyb9m5vAlqYb4vQsK3c ec1Lw0kgjhdCoE9326de+hWWCuytCZcsXGMYyI1PLX0daYpi/wQVcEgx0dRu/In07fr6 8Qc2IahxckyCfej5aA1SL3/U8co1TymT5rGxo8pVYWg/kJ4nKn8fpZOjJybKTuCE6+8g YBmv4asUGdSo5Emk1XKEiMcfZ6wMnBSTSx8l82G4Mc3bG5MPVSWL0X/CAyOP5y/AztJG eCVg8y+VDCj8I+LHbDrArllqhRhsTq34hZFWGsPmw8JW7WQOa3Edaq9vL7Gu56WroDD0 QF0A==
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=DOTbv7K25cYxpC5x/Br3T7yzKshJekunJ8qOG51LxBo=; b=BXpOv0m787HpJJ4ru1QIFz3BR9M6H/iM4HAZdvZv/P4Pq0v+uk8Kv2FGvAjp/C93/v AGlCjci/eWYs5CyO4rnpI5XeE0Kv1nmRxEHF+BqHUU/K3fKiZPfdNZGYs0911wnmhNEM /TuHQxoh5oXcaQ4gvtuhyWEQC54RUnhMA2OmYouPZ5Zu6E8xzepshPz8xpjYIHX+bEtw eaZT4+4YK+JL4kI6DLKtodFJVAKki9Iav/roan/kgF0wM7lithgRC5sSIHnj/XXt8L0P 7zxY4yhW3AuNcz7tF+HNViWqMMMhRDYxOfqVW6vUKH5DSfA//fHMHZYmSzgZVK5Cl62C 6M7Q==
X-Gm-Message-State: AOAM530lELocNpur8Xq3OuOGAQHxI+vGWnrSNYzKlT67383cBYFpm4rM KS5PPg7b7C5TdlDEK1999CfLwQEuLLiVu1sIxynAdss3f/05vQ==
X-Google-Smtp-Source: ABdhPJyT7gfhjFGF3XFdT50l4r9rh6bVQ5lbRdxRgxkTSL417ndEjiRbEY2ev8vvCQkSj2gzcg2pPn1t36xzOaRwRhw=
X-Received: by 2002:a05:6e02:bcf:: with SMTP id c15mr6935873ilu.234.1605126764072; Wed, 11 Nov 2020 12:32:44 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Manu Bretelle <>
Date: Wed, 11 Nov 2020 12:32:32 -0800
Message-ID: <>
To: Tony Finch <>
Cc: DNS Privacy Working Group <>
Content-Type: multipart/alternative; boundary="00000000000097934105b3dab226"
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 20:32:48 -0000

Thanks Tony for the exhaustive list of approaches with their pros and cons,
helping in deciding where the tradeoff may be made.
Having this as an ID or possibly a github repo may make it easier to refer
to/iterate than just this email.

I had attempted to quickly categorize some of those approaches (albeit a
much smaller list) in a matrix in [0] but did not follow through since.



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