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

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 19:07:15 +0000

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.

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Nov 2020 11:50:10 -0800

>     connection adds latency, and would need to be specified carefully

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

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 11 Nov 2020 19:53:33 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Tony Finch
> Sent: Wednesday, November 11, 2020 2:07 PM
> To: [email-masked]
> 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.
>
>
> This specification takes the last option, since it is best for security and 
> not too
> bad for performance.
>
>
> Where can we put the new DNS records to signal that a nameserver supports
> encryption? There are a number of issues to consider:
>
> The following subsections discuss the possible locations, and explain why
> most of them have been rejected.
>
>
> ## In the reverse DNS?
>
> 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.
>
> 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
>
> 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

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 20:11:22 +0000

> can/will publish that information in the zone and if EPP clients are able and

True! I am using "EPP" as a grossly unfair and simplified shorthand for
the whole registry/registrar ecosystem. TBH I think most of the
difficulties are in registrar user interfaces and APIs, rather than EPP. I
would be very grateful if someone could write a more informed and accurate
description of the registr* aspects of how feasible it might be to change
the domain delegation model.

If it's worth revising these notes I will change this part to be less
lazy. Thanks for reading and it and giving feedback!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: Northwest 3 to 5 backing south 7 to severe gale 9, perhaps storm 10
later. Rough, becoming very rough or high. Rain. Moderate becoming poor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 20:25:49 +0000

> result in quite a lot of lift.

Good point, thanks! I haven't thought about this option enough.

One thing that will make it more tricky is nameserver aliases: it's
relatively common for NS records to refer to servers by names that the
server operator does not know. So I expect that an in-band upgrade to TLS
will have to use IP-address-based authentication, if any.

A nice thing about TLSA records is they also tell the client what name to
look for in the server's cert. (I need to make that more explicit in my
notes.)

Tony.

---

From: Manu Bretelle <[email-masked]>
Date: Wed, 11 Nov 2020 12:32:32 -0800

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.

Thanks,
Manu

[0]
https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01

---

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Nov 2020 12:43:36 -0800

> security and not too bad for performance.

Agree strongly, for the reasons you mention.

>   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

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

> DNS, it is incompatible with EPP, so it is not realistically

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

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

> nameserver. Queries for other domains hosted on the same nameserver
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.

> 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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Nov 2020 20:55:37 +0000

> Thanks Tony for the exhaustive list of approaches with their pros and cons,

+many - very useful,
Thanks,
S.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 21:20:32 +0000

> to/iterate than just this email.

Yes! https://github.com/fanf2/draft-dprive-adot

> [0] https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01

Ah, I haven't been paying enough attention to meetings so I missed this! I
think I need the speaker notes to understand it properly :-)

Your title "DoT for insecure delegations" is interesting: one of the
problems with what I have written so far is that it is too much a post-hoc
justification for using TLSA records to support ADoT. So I have built
nameserver authentication on top of TLSA on top of DNSSEC.

One of my unstated assumptions is that DoT will be problematic for TLDs,
and (with QNAME minimization) it matters more for leaf zones, so it is
likely to be deployed there first. But DNSSEC is deployed to a much higher
proportion of TLDs than leaf zones, so there's a good chance I'm wrong.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west. Rough
or very rough. Rain or drizzle. Moderate or poor, becoming good later in west.

---

From: Manu Bretelle <[email-masked]>
Date: Wed, 11 Nov 2020 14:03:18 -0800

> Yes! https://github.com/fanf2/draft-dprive-adot

Thanks!

> think I need the speaker notes to understand it properly :-)

Totally fair, pretty sure there were no speaker notes ;) . The
presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 .
Originally, there was this draft
https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01
and the solutions in the slide deck were compiled from feedback/ideas that
came up while talking with other folks.

> nameserver authentication on top of TLSA on top of DNSSEC.

Speaking of which, I think Brian Dickson did a good job of describing an
"hybrid" approach which I had notes of, but never got to write down
properly. Here is the link:
https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/

My TL;DRed notes, in the context of serving zones across name servers in
(multiple) out-of-bailiwick zones, that I think echoes Brian's more
throughout description:

Other approaches to signalling DoT support to the recursive nameservers may
be through the presence of TLSA record, special record at the name server
side. In the end, the name server zone owner will have to be authoritative,
such authoritative answer can only be validated if it is signed. By
separating zones from nameservers, one can provide DNSSEC signing at the
name server zone level without having to enforce it at the zones which are
served. Having multiple name server zones would:

   - allow enabling DNSSEC on a subset of the nameservers without risking
      impacting all the DNS traffic.
      - allow to stage key roll on a subset of the nameservers, and
      ensuring that in the worst case, only a subset of the traffic is impacted
      in case of mishap.

> proportion of TLDs than leaf zones, so there's a good chance I'm wrong.

yeah, and this is where zones hosted by DNS providers may benefit of this
hybrid approach if the providers are supporting DNSSEC for their name
server zones. But I just quickly checked Route53 and Google Domain, and
none of them have their NS names signed.

Manu

---

From: Tony Finch <[email-masked]>
Date: Thu, 12 Nov 2020 00:00:53 +0000

> came up while talking with other folks.

Ooh, that video has lots of ideas, thanks! I think most of them are
slightly different angles on approaches that I rejected in my notes. (how
do I do a wry emoticon?) I'll try to summarise - please forgive me if I
have misunderstood...

  * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509
    SPKI into a new delegation RRtype. Comes under my "new kind of
    delegation" heading.

    (There's a twist that DSPKI seems to have an authenticator per zone,
    so all servers are expected to share the same private key?)

  * Do9: per-server encryption hint without authenticator inside DS
    records. Most of the badness under my "new DS algorithm" heading,
    but with less key rollover churn. WebPKI authentication.

Joe Abley emphasized what I called the scalability issue. Wes Hardaker
made a slightly different point about correctness and synchronization of
apex and delegation records. Wes's point kind of strengthens the
scalability issue: a design that avoids per-zone configuration of any
kind for scalability reasons also avoids delegation mismatch problems.

Watson Ladd made a good point about decoupling signalling from
authentication. My prejudice was that if you are publishing a 1 bit ADoT
signal in the DNS you might as well publish a 256 bit authenticator; now
that I have gone through the options in detail I still think that is true.
And I think it implies that any approach to ADoT based on in-band
signalling should avoid relying on any records published in the DNS,
because then the in-band signal no longer does anything useful.

[ I've been very bad at looking for and citing previous work, sorry
everyone... I belatedly realise the datatracker doesn't list expired
drafts, oops ]

> https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/

Yes, I think Brian's description is basically the same as what I have in
mind. On top of that I've added a little complication, `dot--` hints so
that when a delegation requires glue, a resolver can still connect
directly over TLS without first getting the TLSA records. I am unsure if
these hints are really needed...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to 50kt,
veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around
dawn, locally 6 mid-channel, backing southwest to south in the afternoon.
Rather rough to rough, occasionally moderate in the south and east, becoming
slight in the south to rather rough in the north by midday, perhaps locally
rough mid-channel, with a low swell throughout. Rain, locally heavy, clearing
before midnight to isolated showers. Good, occasionally moderate to poor this
evening.

---

From: Manu Bretelle <[email-masked]>
Date: Thu, 12 Nov 2020 10:59:21 -0800

>     SPKI into a new delegation RRtype. Comes under my "new kind of

The penultimate slide is a dnscurve like approach.

>     so all servers are expected to share the same private key?)
yes and no, you could have multiple DSPKI records, but it is definitely an
all or nothing, as in all servers would need to provide DoT.

>     but with less key rollover churn. WebPKI authentication.

yop

> kind for scalability reasons also avoids delegation mismatch problems.

yes, anything that will involve the parent will be a nightmare to keep
synchronized unless stuff like CDS, CDNSKEY ... hence CDSPKI work, well as
much as synchronisation is concerned.
The "cloud provider" case, e.g few name servers for many zones is also
tricky. I think in those cases, TLSA may be the best bet as this is under
control of the nameserver, not the zone operator. Then there  may be issue
with being able to opt people in/out. I think in any cases, if you want to
be able to gradually enroll your customers while giving the the choice to
not be enrolled, you essentially need to provide them with a new NS that
supports ADoT and have them move over.

> because then the in-band signal no longer does anything useful.

 Decoupling signalling from authenticating could actually let zone owner
decide to not do ADoT even though the provider supports it.

> these hints are really needed...

That hint could be downgraded, but if not, can be used to fetch the TLSA
record over an unauthenticated TLS connection and then validating it. I
suppose it just obfuscate the  zone, which may be useful *if* multiple name
server names are behind the same IP and/or name server name matches the
zone name (because TLSA record would be against name server name, not zone).
Unless the query to the parent zone was using ADoT, that information may
already be known from someone on-path.

Manu

---

From: Tony Finch <[email-masked]>
Date: Fri, 13 Nov 2020 17:28:23 +0000

Manu Bretelle <[email-masked]> wrote:

> tricky.

I prefer to think of this as the normal common case, since I'm not a cloud
provider and I have many more zones than servers :-)

> I think in those cases, TLSA may be the best bet as this is under

Yes. It can be just different aliases for the same server, where the
aliases differ in whether they have associated TLSA records or not. (I
need to write more about nameserver aliases.)

> already be known from someone on-path.

Yes. (I think I covered all those points in my notes.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fair Isle: South 6 to gale 8. Rough or very rough, occasionally high in
northwest. Rain or squally showers. Good, occasionally poor.

---

From: Peter van Dijk <[email-masked]>
Date: Sun, 15 Nov 2020 19:33:35 +0100

>     different zones on the same server to use encrypted and

(plus, in another email, Tony wrote: "A nice thing about TLSA records
is they also tell the client what name to look for in the server's
cert.")

This looks like a mistake to me, or at least, a choice that would have
to be made very deliberately.

Today, the name through which I reach an NS does not matter - it is not
part of the protocol exchange like the HTTP Host header is. This
simplifies a lot of things, and allows some leeway for mismatches in
names between parents, childs, etc., as long as they reach the same IP.
 
It also seems that any 'split' between which zones on a certain IP
support encryption and which zones do not, would make any opportunistic
proposal obsolete immediately.

I'd like to assume that all transports offered by an NS host the ~same
data (ignoring, for a moment, that we might one day imagine data that
should only be seen over transports with certain security properties,
but I'm imagining that such data would not cover whole zones).

In fact, it would be good if I don't assume. Instead, we should
actively decide whether any such splits are allowed, or forbidden.

I note that the phase2 doc has this text:

9.   A given name server may be authoritative for multiple zones.  As
        such, a name server MAY support use of a secure transport
        protocol for one zone, but not for another.

So in fact, right now we have written down that this is allowed. But I
think it is a mistake.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Tony Finch <[email-masked]>
Date: Tue, 17 Nov 2020 01:21:51 +0000

Thanks for reading and providing feedback!

> to be made very deliberately.

My point above mostly relates to section 5.1 points 7 and 9 of
https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02

I agree that this is very arguable but I think it's hard to avoid.

> names between parents, childs, etc., as long as they reach the same IP.

Right. I need to write more about this issue of nameserver aliases,
something like the text below. (Er but I need to avoid the term "alias"
because that's tied up with CNAMEs which are not allowed for
nameservers...)

> proposal obsolete immediately.

I'm not sure what you mean here because "opportunistic" has multiple
meanings, and they have different implications for how a client might
authenticate a server.

... and now the text below ...

## TLS certificate authentication

The DNS does not currently depend on the name that appears in an NS
target, provided it resolves to the IP address(es) of the intended server.
In particular the NS name does not have to be the server operator's
preferred name. Zone operators sometimes use different nameserver names
because they prefer to avoid glueless delegations, for example.

The widespread use of unofficial nameserver names means it is impossible
for a nameserver to present a certificate that always matches the
`subjectAltName` `dNSName` [RFC 6125] expected by the client. There are a
number of ways to avoid this problem:

  * Authenticate the server by `subjectAltName` `iPAddress`. Unfortunately
    IP address certificates are hard to obtain (though this is likely to
    become easier after [RFC 8738] is deployed). This is only an advantage
    when there is no signal associated with the nameserver's name (such as
    TLSA records) indicating support for encrypted transports, because if
    there is such a signal the client knows what name to expect in the
    certificate.

  * Use the syntax of the name, such as a `dot--` prefix, to indicate that
    the name will match the certificate. This has the disadvantage of
    requiring all delegations to be updated.

  * Ignore certificate name mismatches, and authenticate just the public
    key. This raises the question of how the client can find out the right
    public key: if it can find out the right key why can't it also
    find out the right name? It has the disadvantage that public key
    pinning has a poor operational track record.

  * Use the presence of a DNS record associated with the nameserver name
    to indicate that the server's certificate will match the name. For
    example, TLSA records alongside the nameserver's address records;
    other possible kinds of records for doing this job are discussed in
    the following subsections.

## Nameservers with multiple names

This proposal involves four kinds of name that a nameserver operator needs
to consider:

  * A nameserver's official name, which is used in the vast majority of NS
    records pointing at this server. The presence or absence of a TLSA
    record associated with this name controls whether transport encryption
    is used for the owners of these NS records.

  * A `dot--` tagged name, which can provide better privacy when the NS
    target name is below its own zone cut, and is not necessary in other
    cases.

  * Unofficial names that differ from the server operator's preferred
    name. Zones using unoffical nameserver names are likely to have
    problems using an encrypted transport, for example because of the need
    to keep TLSA records in sync. The server operator can (in principle)
    determine the extent of this problem by auditing all the server's
    zones' apex and delegation NS records.

  * Alternative names that advertise different encrypted transports than
    the official name. A nameserver operator can use different names for
    the same nameserver to support encryption for a subset of zones. This
    might be useful for testing or phased rollout.

A nameserver's support for encrypted transports is a server-wide option,
analogous to the IP addresses and ports that the server listens on.
Whether a zone supports encryption or not is a matter of which records
appear in the DNS, not how the server is configured. A nameserver should
serve the same zones over encrypted transports that it serves over the
corresponding UDP and TCP transports.

[This slightly weird phrasing is to avoid ruling out features like views
or split horizons.]

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Whitby to Gibraltar Point: Southwest 5 or 6, increasing 7 at times. Slight,
occasionally moderate. Rain at first. Moderate or good.

---

From: Peter van Dijk <[email-masked]>
Date: Wed, 18 Nov 2020 21:04:35 +0100

> https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02

I strongly believe point 9 should be removed, for reasons articulated
in my previous email briefly quoted above :)

> meanings, and they have different implications for how a client might

Opportunistic is, perhaps deliberately, vaguely defined. What I think I
mean to say there is 'if an auth NS responds on port 853, it had better
offer me all the data it also has to offer on 53'.

>     there is such a signal the client knows what name to expect in the

For DOTPIN, Ralph Dolmans had the bright insight to suggest not sending
a server name at all (which matches what I said earlier - name servers
have IPs, not really names).

>     pinning has a poor operational track record.

As above. (Not saying that it is the only way, but 'a name server has
no name' has a lot of convenient properties.)

>     the following subsections.

First thought: yes. Second thought: what if the owner of the 'vanity
name' 'aliased' to the NS just copies the TLSAs? At sufficient
deployment, the failure mode is immediate and clear, of course.

>     is used for the owners of these NS records.

Makes sense, that's what puts the NS owner in control of transport,
instead of (or together with) the zone owner.

>     might be useful for testing or phased rollout.

This is neat.

> A nameserver should

Yes!

> [This slightly weird phrasing is to avoid ruling out features like views

Cleverly boxed.
 
Kind regards,

---

From: Tony Finch <[email-masked]>
Date: Wed, 18 Nov 2020 23:09:24 +0000

Peter van Dijk <[email-masked]> wrote:
>
> What I think I mean to say there is 'if an auth NS responds on port 853,
> it had better offer me all the data it also has to offer on 53'.

Yes, I think that makes the most sense.

> >   * Authenticate the server by `subjectAltName` `iPAddress`. [snip]
>

Do you mean not sending in TLS SNI? Yes, that would make sense if we're
not doing name-based auth.

(I have not really thought about SNI in this context; might be useful for
operators who like to use glueful delegations with alternate nameserver
names per zone, though I expect that will end up causing sadness if they
don't control all the zones.)

Even with RFC 8738 acme ip, there's the wrinkle that you can't use acme
dns-01 challenges to get the cert - ironic :-)

> >     key. [snip]

There's another downside to this case: with IP-based or name-based auth,
you can put the CA's public key in the TLSA rather than the server key, so
there's less rollover churn, but that doesn't make sense for key-based
auth.

> >     to indicate that the server's certificate will match the name.
>

That should lead to a certificate name mismatch. If we aren't doing
name-based auth then there won't be an immediate failure; instead it's
likely to go wrong when the server operator rolls their keys or switches
CA, and that delayed failure will be HORRIBLE to debug.

I think there are significant (albeit woolly) advantages to staying as
close as possible to normal webPKI for DoT: much lower congnitive load for
operators who can reuse their https knowledge; deveopers don't have to
write code that's too weirdly different from https; very straightforward
parallel deployment for DoT, DoH, DoQ (if we ever want to support more
transports).

On the other hand you are right that IP address auth is much closer to the
way the DNS works now. I think the other most plausible design for ADoT is
in-band signalling with a strict transport security option and ip-based
auth. (As Ekr said)
https://mailarchive.ietf.org/arch/msg/dns-privacy/Qhn62UWBclwNXjlMaUNoT6M9sMU/

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover: Southwest veering northwest later, 6 to gale 8, perhaps severe
gale 9 later, decreasing 4 to 6 later. Moderate or rough. Showers. Moderate or
good.

---

From: Peter van Dijk <[email-masked]>
Date: Thu, 19 Nov 2020 13:17:47 +0100

> not doing name-based auth.

Yes.

> there's less rollover churn, but that doesn't make sense for key-based

Ah, of course. Then you have the downsides of TLSA with the downsides
of DOTPIN.

> parallel deployment for DoT, DoH, DoQ (if we ever want to support more

That makes sense.

Kind regards,