Subject: Re: [dns-privacy] DPRIVE Interim: 10/29

From: Brian Haberman <[email-masked]>
Date: Fri, 25 Oct 2019 09:25:37 -0400

https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/

On 9/25/19 10:45 AM, Brian Haberman wrote:
> All,
>      We are going to hold a DPRIVE virtual interim meeting on Oct. 29th
> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items are:
> 
> - Review updates to the BCP based on WGLC comments,
> - Review updates to 7626bis based on WGLC comments,
> - Discuss recursive-to-authoritative requirements (-00 draft forthcoming).
> 
> The conference call details will be forthcoming.
> 
> If there are other topics of pressing nature, please let the chairs know.
> 
> Regards,
> Brian & Tim
>

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 25 Oct 2019 14:27:16 +0000

>> - Discuss recursive-to-authoritative requirements (-00 draft forthcoming).

Will we be able to review the forthcoming recursive-to-authoritative requirements draft before the interim meeting?

--Paul Hoffman

---

From: Brian Haberman <[email-masked]>
Date: Fri, 25 Oct 2019 11:04:25 -0400

Hi Paul,

> Will we be able to review the forthcoming recursive-to-authoritative requirements draft before the interim meeting?

I have asked the authors to post either a -00 draft or a doc on GitHub
before the interim.

Brian

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 25 Oct 2019 18:58:55 +0000

I just submitted my final changes to Benno and Alex and put the ball in their court to send something over the weekend or on Monday morning in Austria or the Netherlands. It is a very early -00 and so intended to mostly spur WG discussion.

Jason

On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Paul,

    Brian

---

From: Alexander Mayrhofer <[email-masked]>
Date: Mon, 28 Oct 2019 11:23:50 +0100

I've just posted the -00 individual submission version:

https://tools.ietf.org/id/draft-lmo-dprive-phase2-requirements-00.txt

Sorry for the delay, but i hope that people still have some time to
look through that draft.

best,
Alex

On Fri, Oct 25, 2019 at 8:59 PM Livingood, Jason
<[email-masked]> wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Brian Haberman <[email-masked]>
Date: Mon, 28 Oct 2019 12:59:06 -0400

All,
     The Secretariat has been investigating intermittent audio issues
during recent meetings and they are working with the WebEx team to find
the source of the problem.

      If you encounter audio issues during the DPRIVE interim on 10/29,
please report the problem *during* the meeting. To do that within WebEx,
you can:

1. Select 'Help'.
2. Select the 'Send Problem Report', under Help’s drop-down options.
3. Click 'Send a Problem Report' and wait for the process to complete
and generate the report.
4. Please provide the network logs by following:
https://help.webex.com/en-us/WBX000026383/WBX-Tracer

Regards,
Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 28 Oct 2019 21:37:26 -0700

Hi, everyone interested in ADoT,
I'm planning on being on the call, although given the early hour for me I
can't be sure I'll be on my game as much as usual...

In the interests of getting all the ideas I have after reading the -00
draft, I thought I'd send them to the list, and maybe they can be discussed
on the call, time permitting.

Simple notion up front: add an EDNS flag or OPT code to signal ADoT support
(or a bit field of all the supported transport types) on a given IP
(analogous to the RA flag), and possibly include the canonical name(s) of
the server at that IP, if the query include EDNS. This limits downgrades to
on-path adversaries who block port 853 and modify port 53 traffic. Maybe
SIG(0) or TSIG can further prevent downgrades by on-path attackers who
would modify UDP/TCP port 53?

Certificates for DoT and DoH should really be DANE/TLSA entries. We're
literally talking DNS here, so it would be particularly shortsighted not to
standardize on this. It also potentially decouples from any hard dependency
on particular CA support matrix, notwithstanding that the authoritative
server might be using a CA-issued certificate. Having the ability to
validate without needing to unilaterally trust some particular set of CAs
is a feature not a bug.

State exhaustion protection mechanism, optionally use TCP cookies during
handshake, regardless of TLS or not. This limits the TCP impact of needing
established connections to do the TLS stuff to legitimate TCP connections
only. Servers can limit the number of connections doing TLS handshakes, and
prioritize those. The, use of aggressive timers on those prioritized
connections protects against deliberate DOS via "slow transaction" attacks.
Handshake-complete connections can be resumed, so making them lower
priority and having aggressive connection dropping on those has
comparatively low impact (since session resumption is cheaper than redoing
the handshake). Experimentation is needed to establish recommendations on
all the appropriate values (timeouts, number of sessions to support in each
state, etc.)

The rest of the ideas mostly relate to the question "when is using DoT
really optional, vs strongly desirable?".

I have a few suggestions along that line, as well as a few additional
observations.

First, there is a strong correlation between the first time any client
queries a given name, the visibility of the corresponding R2A query
(presuming no ADoT), and the subsequent client data traffic (even with
HTTPS).
The R2A (recursive to authoritative) query is a strong indicator that the
name isn't cached (and may never have been cached).
This correlation may not be that important per se, but identifying it as
somewhat distinctive means there's a reason to potentially look at the
implications of that (from the perspective of ADoT being "strongly
desirable").

In contrast, very popular domain names (and qtypes) are likely to be
heavily served from the cache. If cache refresh (what was once identified
in the HAMMER draft) is done for popular cache entries, there would no
longer be any identifiable query triggering the R2A lookup, and in
particular no timing side channel for identifying even a single DNS client.

What I'm suggesting is, using ADoT predominantly (or even exclusively) for
"cold cache" lookups, and doing "cache refresh" lookups without ADoT, is
one way to minimize the TLS overhead, which incurs a cost on the authority
server (mostly CPU) and a penalty on the recursive (mostly latency, and
maybe some CPU). Refresh without TLS would have lower latency, IMHO.

IMHO, the same rationale for "cold cache" also applies to "ECS" (EDNS
client subnet). First instance (of a particular ECS parameter value), use
ADoT; refresh, ADoT is optional.

The other question (observation?) is that ADoT is a poor substitute for
DNSSEC. I.e. unsigned zones might seem like attractive reasons to force DoT
for transport, but doing so would basically amount to "security theater".
It would also discourage, rather than encourage, use of DNSSEC validation.
It would be justifiable for an authority operator to respond "REFUSED" for
ADoT queries doing "refresh cache" queries on unsigned domains, at least
during periods of heavy load. Or maybe some new error code or EDE to signal
"retry on non-TLS connections".

It remains an open (and perhaps interesting) question of the relative
overhead of DNSSEC validation when compared with TLS transport. It might be
interesting to compare those based on crypto algorithms (for negotiated TLS
connections, and for DNSSEC zones), and based on various TTL values.

Having validation of DNSSEC signed zones, on popular domains being
refreshed without ADoT, would potentially be the "sweet spot" for security
and privacy. Security, by having cryptographically signed zone data, and
privacy by the aforementioned "cold cache" and "cache refresh" distinction.

This might be where the EDNS signaling available directly between the
recursive and authoritative, would allow the authoritative server to make
the informed decision to reply with UDP instead of over the ADoT
connection, if/when it experiences significantly increased load. The
recursive could always try to use ADoT, but get signal(s) from the
authority server to limit ADoT to "cold cache" queries only in response to
load problems.

Finally, I'd like to announce the following:
*GoDaddy now has four ADoT servers in its OTE environment.*
They are ns01/ns02, and pdns01/pdns02 in ote.domaincontrol.com, with
domains dnsczar.com and sheldns.com on those respective nameserver pairs.
The TLS certificate names match the NS names for those domains.
The test domains are also DNSSEC signed.
(The domaincontrol.com zone is not yet signed, so no DANE/TLSA for the
certs just yet.)

Please feel free to test against those domains, and feedback on that
testing is being actively solicited. Send feedback to [email-masked]
please.

All credit for the DoT goes to my colleague Michael Sheldon (as do all the
GoDaddy DNS software kudos.)
We are supported by our excellent ops team including Brian King, Jason
Lynch, Frank Even, and Tyler Stanton.

Brian Dickson

On Mon, Oct 28, 2019 at 3:24 AM Alexander Mayrhofer <
[email-masked]> wrote:

> > I just submitted my final changes to Benno and Alex and put the ball in
> their court to send something over the weekend or on Monday morning in
> Austria or the Netherlands. It is a very early -00 and so intended to
> mostly spur WG discussion.
> >
> > Jason
> >
> > On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >     Hi Paul,
> >
> >     > Will we be able to review the forthcoming
> recursive-to-authoritative requirements draft before the interim meeting?
> >

---

From: Rob Sayre <[email-masked]>
Date: Mon, 28 Oct 2019 21:44:29 -0700

I won't be on the call, but I think one question might be good to add:

"Why are the requirements described in the draft better than
centralization?"

It seems good that resolver traffic patterns are being questioned, but I
had this thought in the back of my mind.

thanks,
Rob

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Tue, 29 Oct 2019 11:29:52 +0000

Another experience return (being on a couple of those 'broken' calls):
- audio can become one-way: participants can hear but not talk (cannot remove the mute button in my case !) => use chat / jabber to pass your message could be a work-around
- if Internet audio does not work, then use your phone to call webex (but $ in some cases)

Let's hope that we will not experiment problems later today

-éric

On 28/10/2019, 17:59, "dns-privacy on behalf of Brian Haberman" <[email-masked] on behalf of [email-masked]> wrote:

    All,

    1. Select 'Help'.
    
    Regards,
    Brian

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Oct 2019 14:19:42 +0000

Here are a few responses to the initial draft. I will try to be on the call unless we lose power again.

There are many parts of the "core requirements" that seem out of place.

- Resolvers have never had to understand the different between the root zone and TLDs and SLDs and "other", so introducing that here might cause bikeshedding and lack of adoption. A simpler core requirement would be that DoT is required between resolvers and any interested authoritative server.

- QNAME minimization is orthogonal to adding cryptographic privacy. If you have a cryptographic tunnel, QNAME minimization adds overhead and the risk of additional round trips. On the other hand, some resolvers are perfectly happy using QNAME minimization all the time, so they shouldn't have to know whether to change settings if DoT is in use.

- The aggressive caching requirement mixes up aggressive caching and normal caching in the all-caps bit. Aggressive caching will reduce the number of TLS connections you need to set up, so it is a positive, but it is unclear how requiring it in order to use ADoT could be enforced.

- DNSSEC validation is orthogonal to adding cryptographic privacy.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Oct 2019 14:49:44 +0000

Greetings again. I was surprised, but happy, to not see a requirement in the list for authentication of servers in the list. However, I suspect that this might have been an oversight, and the endless debate on authentication requirements will start as soon as there is a proposed protocol document.

My preference would be that the core requirement is that ADoT servers use either IP address or DNS name authentication in their certificates, but that the certificates can be issued by any CA, including being self-issued. The core requirement could also go on to say that resolvers be able to authenticate servers for logging purposes, but not be required to break TLS connections if the server's identity cannot be authenticated against the resolver's set of trust anchors.

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Oct 2019 08:02:42 -0700

Hi Paul,

On Tue, Oct 29, 2019 at 7:50 AM Paul Hoffman <[email-masked]> wrote:

> Greetings again. I was surprised, but happy, to not see a requirement in
> the list for authentication of servers in the list. However, I suspect that
> this might have been an oversight, and the endless debate on authentication
> requirements will start as soon as there is a proposed protocol document.
>
> My preference would be that the core requirement is that ADoT servers use
> either IP address or DNS name authentication in their certificates, but
> that the certificates can be issued by any CA, including being self-issued.
> The core requirement could also go on to say that resolvers be able to
> authenticate servers for logging purposes, but not be required to break TLS
> connections if the server's identity cannot be authenticated against the
> resolver's set of trust anchors.
>
>
To be sure I understand you correctly, in the second case, the connection
would be made to some IP address (e.g. NASA's 198.116.4.181).  The
recursive resolver logs the details of the certificate, but it continues
with the connection even if the CA NASA uses for the certificate is not
known to the resolver?  What does it do in the face of other certificate
errors like expired certificates or certificates presenting a different
name?

I have to say that I'm pretty surprised by the idea that TLS in this
context should behave any differently than TLS in application layer
contexts, and I'm a little concerned about having configuration options for
this that amount to "ignore errors of types $FOO".  Accepting self-signed
certificates is a known configuration, so I get that, but if someone has
configured roots of trust, accepting other certificates outside the roots
of trust in the configuration is pretty odd practice.

Just my two cents,

Ted

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Oct 2019 15:26:48 +0000

On 10/29/19 8:02 AM, Ted Hardie wrote:
> To be sure I understand you correctly, in the second case, the connection would be made to some IP address (e.g. NASA's 198.116.4.181).  The recursive resolver logs the details of the certificate, but it continues with the connection even if the CA NASA uses for the certificate is not known to the resolver?  What does it do in the face of other certificate errors like expired certificates or certificates presenting a different name?

It continues. This is exactly how opportunistic encryption is defined.
  
> I have to say that I'm pretty surprised by the idea that TLS in this context should behave any differently than TLS in application layer contexts, and I'm a little concerned about having configuration options for this that amount to "ignore errors of types $FOO".

TLS in application layers can specify that opportunistic encryption, yes?

>  Accepting self-signed certificates is a known configuration, so I get that, but if someone has configured roots of trust, accepting other certificates outside the roots of trust in the configuration is pretty odd practice.

Do you feel that there is a requirement that all recursive resolvers use the same set of trust anchors? If not, and if you are against the use of opportunistic encryption in this case, who will decide what set of trust anchors all resolvers in all jurisdictions will use?

--Paul Hoffman

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Oct 2019 09:01:21 -0700

Hi Paul,

On Tue, Oct 29, 2019 at 8:27 AM Paul Hoffman <[email-masked]> wrote:

> > To be sure I understand you correctly, in the second case, the
> connection would be made to some IP address (e.g. NASA's 198.116.4.181).
> The recursive resolver logs the details of the certificate, but it
> continues with the connection even if the CA NASA uses for the certificate
> is not known to the resolver?  What does it do in the face of other
> certificate errors like expired certificates or certificates presenting a
> different name?
>
Just to be clear, it's my experience that accepting self-signed
certificates from peers does not equate to accepting certificate errors.
The situation in which you set up a connection to n.n.n.n and get a self
signed certificate saying "example.com" and when you set up a connection to
n.n.n.n expecting "example.com" and get a cert back for "accident.example"
are pretty distinguishable. I would expect some configurations to accept
the first without issue; I find accepting the second deeply odd.

> this that amount to "ignore errors of types $FOO".
>
I think you are using "opportunistic encryption" to mean something
different from what I mean by it.  What I mean by it is "use it when you
can, even if you don't know in advance you can".  Testing for DoT before
using a DNS resolver on UDP 53 and using it if you find it is
"opportunistic encryption", for example.

> >  Accepting self-signed certificates is a known configuration, so I get
> that, but if someone has configured roots of trust, accepting other
> certificates outside the roots of trust in the configuration is pretty odd
> practice.
>
> Do you feel that there is a requirement that all recursive resolvers use
> the same set of trust anchors?

No.

> If not, and if you are against the use of opportunistic encryption in this
> case,

See above.  I don't think I'm against opportunistic encryption.  I think
I'm against starting to exchange traffic over a TLS connection with an
identifiable error.  There are degrees there, obviously.  Some folks would
say an expired but correct certificate should be logged but accepted, but a
flat out "wrong name presented" would likely get different treatment.

who will decide what set of trust anchors all resolvers in all
> jurisdictions will use?
Everyone will decide who they accept?  That's how the WebPKI works, for all
its shuffling glory, and with ACME/Let's Encrypt it has gotten very easy to
get a certificate that will often be accepted.

Just my two cents,

Ted

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 12:53:59 -0400

FWIW, my expectation has been that ADoT would use TLSA-like authentication,
with no trust anchors other than DNSSEC (and nothing resembling the WebPKI).

On Tue, Oct 29, 2019 at 12:01 PM Ted Hardie <[email-masked]> wrote:

> signed certificate saying "example.com" and when you set up a connection
> to n.n.n.n expecting "example.com" and get a cert back for
> "accident.example" are pretty distinguishable. I would expect some
> configurations to accept the first without issue; I find accepting the
> second deeply odd.
>
>
>> If not, and if you are against the use of opportunistic encryption in
>> this case,
>
>
> Everyone will decide who they accept?  That's how the WebPKI works, for
> all its shuffling glory, and with ACME/Let's Encrypt it has gotten very
> easy to get a certificate that will often be accepted.
>
> Just my two cents,
>
> Ted
>
> --Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Oct 2019 10:07:29 -0700

Top-reply, which I think can potentially address all the underlying issues:
Make DANE support a SHOULD, along with publishing corresponding TLSA
records at the FQDN of the DNS server a SHOULD. Make the recommendation
that the certificate served include the full chain including CA cert.
This would enable all forms of certificate issuance (public CA or not) and
validation type (cert chain or end entity) workable for doing certificate
validation.

I think this means that if both parties follow the recommended practice,
that even self-signed certs can be validated through the DNSSEC validation
plus the TLSA validation mechanisms.
The only reliance would be on the DNSSEC root trust anchor. That is
mandated when DANE is used, so it can be relied upon for all
implementations that follow the recommendations.
(Root trust anchor algorithms will always be a long-term thing to be
concerned about, but that is really a global issue for DNSSEC and
validating resolvers, not specific to this particular use.)

Brian

---

From: Paul Wouters <[email-masked]>
Date: Tue, 29 Oct 2019 13:10:03 -0400 (EDT)

> Do you feel that there is a requirement that all recursive resolvers use the same set of trust anchors? If not, and if you are against the use of opportunistic encryption in this case, who will dec…

Ideally, with TLSA records involved, DNS resolvers wouldn't need any
webpki based external CA trust anchors, and things would have valid
verification chains using DNSSEC. If you don't, then all the same issues
from mozilla and apple and windows having a different set of trusted
CA's will affect encrypted DNS between resolvers and auth servers. And
likely means a restricted artificial market with only a few accepted
CAs. Which is all irrespective of the Opportunisitc behaviour.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Oct 2019 11:50:48 -0700

Does anyone who was on the call, have the URI of the github doc, please?

Off-list response is fine.

Brian Dickson

On Fri, Oct 25, 2019 at 8:04 AM Brian Haberman <[email-masked]>
wrote:

> > Will we be able to review the forthcoming recursive-to-authoritative
> requirements draft before the interim meeting?
>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Oct 2019 12:06:50 -0700

On Tue, Oct 29, 2019 at 9:54 AM Ben Schwartz <[email-masked]> wrote:

> FWIW, my expectation has been that ADoT would use TLSA-like
> authentication, with no trust anchors other than DNSSEC (and nothing
> resembling the WebPKI).
>
> Which certificate usage are you thinking of, in RFC 6698 terms?

Generally, I think TLSA-like authentication rooted in DNSSEC validation is
fine.  But I remain pretty much of the opinion that if you get a
certificate via that method that is "wrong" for values of wrong like
"presented the wrong IP address or name in the cert"  or "fails DNSSEC
validation" then you should do more than log the error.

I also would like to point out that there are cases where you might have an
authoritative server responding to recursive resolvers where there is a
root of trust between them but where DNSSEC may not be validated:  split
DNS.  Imagine for a moment that enterprise.example has a hierarchy that
includes FQDNs like hostname.campus.internal.enterprise.example .  Each
campus has its own recursive resolver, but they all talk to nameservers
like ns.internal.enterprise.example.  In cases like those, the desire of
the enterprise to not show its internal structures may mean that they do
not wish to use DNSSEC to secure anything in internal, but they likely have
a shared root of trust between the recursive resolvers and the
authoritative server.

Put another way, I think you may need to support authentication using PKI
trust anchors as well.

 regards,

Ted

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Oct 2019 12:20:00 -0700

On Tue, Oct 29, 2019 at 12:07 PM Ted Hardie <[email-masked]> wrote:

> I also would like to point out that there are cases where you might have
> an authoritative server responding to recursive resolvers where there is a
> includes FQDNs like hostname.campus..internal.enterprise.example .  Each
I think that is a very important use case, and also a good one to
illustrate the differences between the PKI model and the DNSSEC model.

PKI requires CRL/OCSP to handle any key problems or certificate revocation
or anything...
DNSSEC revocation can be done via DNS very quickly/scalably, although it
does also mean temporary loss of service if the new keys aren't also
available simultaneously. (That points to good BCP documents on managing
stuff.)

Distributing a localized DNS trust anchor is fairly straightforward, and I
have used such trust anchors previously in those environments. They work
exactly like you would expect. (At least for unbound, that is.)

Scaling for campuses works very well when you delegate from the signed
parental zone, and distribute the parental zone's trust anchor. Same model
as root DNSSEC trust anchor, different starting point.

Brian

>>> signed certificate saying "example.com" and when you set up a
>>> connection to n.n.n.n expecting "example.com" and get a cert back for
>>>> >  Accepting self-signed certificates is a known configuration, so I
>>>> get that, but if someone has configured roots of trust, accepting other
>>>> Do you feel that there is a requirement that all recursive resolvers
>>>> use the same set of trust anchors?
>>>
>>>
>>> No.
>>>
>>>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 16:58:38 -0400

>> Which certificate usage are you thinking of, in RFC 6698 terms?

I'm not very familiar with these terms, but I think I mean usage 2: "trust
anchor assertion".

> validation" then you should do more than log the error.

I agree: validation failure should generally be fatal.  (I expect we'll
need fallback behavior for some scenarios, but not validation failures.)

> a shared root of trust between the recursive resolvers and the

This resembles the ongoing experiment
<https://engineering.fb.com/security/dns-over-tls/> between Facebook and
Cloudflare, where both parties have agreed to speak DoT by hardcoding the
relevant parameters and special-casing the relevant authoritative servers.
They didn't need an ADoT standard to make this possible, because the
connection is a "closed system" based on an agreement between the two
parties.

In your corporate-internal scenario, the recursive and authoritative
servers are even more closely tied, being operated and controlled by the
same party, so a secure upgrade protocol is much less relevant than on the
open internet.  The admins can hardcode whatever authentication procedure
they want.  They can even use pre-shared keys!

Leaving that aspect aside, if we suppose that enterprise.example is a
signed parent zone, and internal.enterprise.example is an unsigned child
zone, we can still potentially enable DNSSEC-rooted ADoT to
ns.internal.enterprise.example, if we can find a way to put its TLSA data
in the parent zone.  I think this is worth attempting.

> trust anchors as well.

Assuming PKI is used to validate the nameserver's name, I'm not sure it's
sufficient, because this name is potentially attacker-controlled.  If the
parent zone is unsigned, I think opportunistic privacy is likely the best
we can offer.

 regards,

---

From: Ted Hardie <[email-masked]>
Date: Tue, 29 Oct 2019 15:54:26 -0700

Clipping away a bit where we appear to agree.

On Tue, Oct 29, 2019 at 1:58 PM Ben Schwartz <[email-masked]> wrote:

Agreed, they could also use pre-shared keys.  But that means that we should
not require in the standard that they use a specific method, but provide a
method that works for the common case and allow for methods where other
things are driven by specific deployment conditions.

I would really like to see a sketch of the design for that before it gets
to be a foundation of the approach.  I can picture both large flat zones
and deep hierarchies where it could end up being a real tangle.  But since
that tangle is based on my headcanon of the design, it's liable to being
very badly off.

I'm not sure what you mean by control the name here.  To save me tilting at
strawmen, would you mind elaborating?

thanks,

Ted

 regards,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2019 17:01:41 -0700

On Tue, Oct 29, 2019 at 3:55 PM Ted Hardie <[email-masked]> wrote:

> Agreed, they could also use pre-shared keys.  But that means that we
> should not require in the standard that they use a specific method, but
> provide a method that works for the common case and allow for methods where
> other things are driven by specific deployment conditions.
>
> I'm not sure what you mean by control the name here.  To save me tilting
> at strawmen, would you mind elaborating?
>

Ben,

Is what you're saying here that .com provides the NS record for example.com
and that may not itself be example.com, but instead ns.server.invalid, and
therefore if you can't trust .com then it doesn't matter if
ns.server.invalid has a WebPKI cert?

-Ekr

>>>> See above.  I don't think I'm against opportunistic encryption.  I
>>>> think I'm against starting to exchange traffic over a TLS connection with
>>>> an identifiable error.  There are degrees there, obviously.  Some folks
>>>> would say an expired but correct certificate should be logged but accepted,
>>>> but a flat out "wrong name presented" would likely get different treatment.
>>>>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 20:44:44 -0400

>> that tangle is based on my headcanon of the design, it's liable to being
I was thinking of the proposals to encode the TLSA data (and probably some
other NS-related info) in a "creatively repurposed" DS record (e.g. here
<https://mailarchive.ietf.org/arch/msg/dns-privacy/G2BwaCvc7_G-NLkf1S51G4DGb6Q>).
That would allow a signed parent zone to make verifiable claims about the
child zone's configuration, even if the child is unsigned (i.e. has no
other DS records).

This is by no means a complete or solid proposal: even the people who've
proposed it seem to have some concerns.

> Is what you're saying here that .com provides the NS record for
> example.com and that may not itself be example.com, but instead
> ns.server.invalid, and therefore if you can't trust .com then it doesn't
> matter if ns.server.invalid has a WebPKI cert?
>

My understanding is that one has no choice but to trust the parent zone,
even with DNSSEC.  I was more thinking of an on-path adversary who can
intercept the NS query and reply with any response of their choosing.
Thus, instead of "ns.example.com.", I get "ns.attacker.example.", which (as
you said) will happily prove that it is ns.attacker.example.

To put it another way: a recursive resolver has no way to distinguish
between an unsigned parent and an on-path adversary.  (I'm assuming that
communication with the parent zone authoritative is over cleartext DNS.)

>>>>>> > I have to say that I'm pretty surprised by the idea that TLS in
>>>>>> this context should behave any differently than TLS in application layer
>>>>> Everyone will decide who they accept?  That's how the WebPKI works,
>>>>> for all its shuffling glory, and with ACME/Let's Encrypt it has gotten very

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2019 17:52:31 -0700

On Tue, Oct 29, 2019 at 5:44 PM Ben Schwartz <[email-masked]> wrote:

>>> <https://engineering.fb.com/security/dns-over-tls/> between Facebook
>>> and Cloudflare, where both parties have agreed to speak DoT by hardcoding
>>> the relevant parameters and special-casing the relevant authoritative
>>> servers.  They didn't need an ADoT standard to make this possible, because
>>> the connection is a "closed system" based on an agreement between the two
>>> parties.
>>>
>>> I would really like to see a sketch of the design for that before it
>>> gets to be a foundation of the approach.  I can picture both large flat
>>> zones and deep hierarchies where it could end up being a real tangle.  But
>>> since that tangle is based on my headcanon of the design, it's liable to
>>> being very badly off.
>>>
>>
>>> Assuming PKI is used to validate the nameserver's name, I'm not sure
>>> it's sufficient, because this name is potentially attacker-controlled.  If
>>> the parent zone is unsigned, I think opportunistic privacy is likely the
>>> best we can offer.
>>>
> Thus, instead of "ns.example.com.", I get "ns.attacker.example.", which
> (as you said) will happily prove that it is ns.attacker.example.
>

Yes, I totally agree with this.  My assumption had just been that we should
assume that we were incrementally deploying but that your target was all
TLS. ISTM that it's going to be very hard to reason about the security
properties here if each step in the recursive resolution process isn't
protected.

-Ekr

>>>>>> connection to n.n.n.n expecting "example.com" and get a cert back
>>>>>> for "accident.example" are pretty distinguishable. I would expect some
>>>>>>> If not, and if you are against the use of opportunistic encryption
>>>>>>> in this case,
>>>>>>
>>>>>>

---

From: Brian Dickson <[email-masked]>
Date: Tue, 29 Oct 2019 18:03:49 -0700

> matter if ns.server.invalid has a WebPKI cert?
(Apologies in advance for "DNS-splaining" this, but I'd rather do that than
assume knowledge of some tid-bit.)

I am neither Ben nor Ted, but I think I may get the gist of the conundrum
that exists due the "unsigned delegation" (which was labeled "unsigned
child zone", but can even be the case if the child zone is signed but not
securely delegated.)

The term for the child zone or any of the child's descendants, if any are
signed, is an "island of security". That refers to a sub-tree of DNS which
contiguous and where every delegation in that tree is signed, and every
other record type is signed.

What the problem is concerned with, is that the unsigned delegation creates
a gap in the security coverage at the child, where the authoritative data
for the child zone is not DNSSEC signed, and therefore potentially
vulnerable to "cache poisoning" attacks.

And a successful cache poisoning turns an otherwise benign record into an
"attacker controlled" record.

The (literal) key to preventing this, is to put all of the relevant
components under a signed parent, where that signed parent is one such
"island of security".  That "island parent" would be DNSSEC signed, and the
secure entry to that zone (the zone's KSK hash) would be the "trust anchor"
for everything below it.

Here are some example "meat" of how this might look:
com has a secure delegation to example.com, with NS of ns.server.example.net
(out of bailiwick for example.com to avoid any short cuts).
com has the corresponding DS record for example.com, which matches the
DNSKEY at the apex of the example.com zone.
example.com is a signed zone.
internal.example.com is an unsigned delegation; it has the NS record
pointing to the appropriate server for internal.example.com.
example.com does NOT have a corresponding DS record since
internal.example.com is an insecure delegation.

HOWEVER, it is entirely possible that internal.example.com is the top of
the internal-only "island of security", and has DNSKEY records etc.
(Even if there is a level of totally unsigned DNS between the signed parent
and for example the signed grandchild, the installation of the trust anchor
of the grandchild creates the necessary element for DNSSEC validation of
anything in that grandchild's island of security.)

NB: The only missing component that makes internal.example.com an insecure
delegation, is the lack of the DS record in the parent zone at the zone cut.

Everything at/below internal.example.com can be DNSSEC signed and would be
possible to validate by any resolver that has the trust anchor for
internal.example.com configured.

At that point, assuming that all the resolvers referred to in the original
example have this trust anchor, everything DANE is available to use.

There are many different ways that the the certificates can have TLSA
records built for them.

Possible examples include:
Use of TLSA type 2 records that are identical for all certificates, where
the type 2 record corresponds to whatever CA (internal or otherwise, root
or intermediate) issued the certificates, at the owner name of the host of
each individual certificate.
Use of (signed) CNAME records that point to a single TLSA type 2 record ...
Use of TLSA type 3 (end entity) records that correspond to the actual
certificate itself (raw key, full certificate, or fingerprint), for each
issued certificate, at the owner name of the host in the certificate.

E.g. ns.internal.enterprise.example TLSA 2 x x { stuff }, and the cert for
ns.internal.enterprise.example has a cert chain that includes a cert
matching { stuff }.
The DNSSEC signature on this record validates based on the trust anchor for
"internal.example.com". This guarantees the validity of the TLSA record,
which can then be used to validate the certificate.

Note that the TLSA of type 2 or 3, does not automatically mean that the
certificate was NOT issued by a WebPKI CA. It only means that the WebPKI
validation does not depend on trusting the root CA that issued the
certificate.

Hopefully this is a clear enough description of what is meant, and
demonstrates a robust enough security model.

(The resolver SHOULD implement DNSSEC validation and TLSA certificate
validation, and if the authority server is using TLSA records, it MUST sign
the zones. The trust requires sharing the root trust anchor from the
authority server to the resolver. No sharing of private keys is required
outside of the DNSSEC signer, and the management of the TLS materials is
orthogonal to the validation model.)

The DANE model is very flexible, and as a result this general design
supports pretty much any imaginable scenario including this "split DNS" one.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 29 Oct 2019 21:27:17 -0400

On Tue, Oct 29, 2019 at 8:53 PM Eric Rescorla <[email-masked]> wrote:

>> I was thinking of the proposals to encode the TLSA data (and probably
>> some other NS-related info) in a "creatively repurposed" DS record (e.g.
>> here
>>>> I'm not sure what you mean by control the name here.  To save me
>>>> tilting at strawmen, would you mind elaborating?
>>>>
>>>
>>> Ben,
>>>
> Yes, I totally agree with this.  My assumption had just been that we
> should assume that we were incrementally deploying but that your target was
> all TLS. ISTM that it's going to be very hard to reason about the security

Yes, it's hard, but I think it's worthwhile, because the prospect of
getting the root to offer ADoT seems very distant to me.  Since the root is
signed, DNSSEC seems like the clearest path to secure ADoT bootstrap in the
foreseeable future.

>>>>>>>> >  Accepting self-signed certificates is a known configuration, so
>>>>>>>> I get that, but if someone has configured roots of trust, accepting other
>>>>>>>> Do you feel that there is a requirement that all recursive
>>>>>>>> resolvers use the same set of trust anchors?
>>>>>>>
>>>>>>>
>>>>>>> No.
>>>>>>>
>>>>>>>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 Oct 2019 18:32:13 -0700

On Tue, Oct 29, 2019 at 6:27 PM Ben Schwartz <[email-masked]> wrote:

>>> Put another way, I think you may need to support authentication using
>>>>>> PKI trust anchors as well.
>>>>>>
>>>>>
> getting the root to offer ADoT seems very distant to me.
>

Why? Do we have estimates of the load level here as compared to (say) Quad9
or 1.1.1.1?

Since the root is signed, DNSSEC seems like the clearest path to secure
> ADoT bootstrap in the foreseeable future.
>

Perhaps.

-Ekr

---

From: Christian Huitema <[email-masked]>
Date: Tue, 29 Oct 2019 18:03:51 -0700

On 10/29/2019 5:01 PM, Eric Rescorla wrote:
> example.com <http://example.com> and that may not itself be
> example.com <http://example.com>, but instead ns.server.invalid, and

We want to assure integrity and confidentiality of the exchanges, which
clearly requires authenticating the server. So if for .com the server
"a.gtld-servers.net" provides for "privateoctopus.com" the NS record
"ns-125.awsdns-15.com", I want to authenticate "ns-125.awsdns-15.com".
That's exactly how it is supposed to work.

The related question is whether "ns-125.awsdns-15.com" is in fact
authorized to provide answers for "privateoctopus.com". ADOT provides
some assurance of that, but if you want proofs the answer is DNSSEC.

But then, there is a special concern for the scenario in which the
authoritative server has been corrupted and sends back a bogus A record
for "www.example.com", pointing to an attacker-controlled copy of the
original server, and then using DNS based verification process to obtain
a bogus PKI certificate for the copy.

In practice, issuance of domain based PKI certificates relies on the
integrity of the DNS. ADOT plays a role in that integrity. It would be
better if the integrity of ADOT did not depend on PKI, because that
would introduce a circular dependency. Using DANE instead of PKI there
seems prudent.

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 29 Oct 2019 22:36:54 -0400

>Why? Do we have estimates of the load level here as compared to (say) Quad9

The load has nothing to do with it.  Surely you're aware of the morass
of root server administrative politics with acronyms like RSSAC and
RZERC.

On the other hand, running your own root mirror is easy.  Knock
yourself out.

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Wed, 30 Oct 2019 03:29:59 +0000

On 30 Oct 2019, at 01:32, Eric Rescorla <[email-masked]> wrote:
> 
>> Yes, it's hard, but I think it's worthwhile, because the prospect of getting the root to offer ADoT seems very distant to me. 
>> 
> Why? Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1?

The root server operators publish statistics on the traffic they get. Links for some of their data can be found at https://root-servers.org.

The anycast cluster for a.root-servers.net alone currently handles upwards of 8B queries/day - roughly 100,000 queries/second. That’s steady state. The numbers would go *far* higher than that during a Mirai-style DDoS attack.

It’s going to be a challenge to get authoritative servers handling those sorts of query levels to support DoT (over TCP?). FWIW solving the non-trivial operational and engineering issues will be the easy bit. Solving the layer-9 issues will be harder. I expect that also holds for DoT support at authoritative servers for important TLDs or the DNS hosting platforms from the likes of Akamai, Dyn, UltraDNS, etc that handle very high query rates.

I suppose someone could ask RSSAC* for their opinion on deploying DoT at the root. And having lit the blue touchpaper, I will now run away at great speed to watch the ensuing firework display. :-)

* Other ICANN advisory committees are available.

---

From: Jim Reid <[email-masked]>
Date: Wed, 30 Oct 2019 03:48:05 +0000

On 30 Oct 2019, at 01:32, Eric Rescorla <[email-masked]> wrote::
> Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1?

NB Offlist

Take a look at how long it took for the root server operators (RSOs) to make their infrastructure DNSSEC-capable. Each of them understandably took their own decisions about that: provisioning, budgeting, upgrade & procurement cycles, resourcing, testing, project scheduling, etc. A similar exercise would need to happen before DoT at the root was a viable prospect. Assuming the RSOs unanimously agreed that that was a good idea. You’d probably need to get ICANN Board approval too, like we had for the KSK rollover. Which means getting consensus in various ICANN committees who would have to be consulted.

---

From: Jim Reid <[email-masked]>
Date: Wed, 30 Oct 2019 03:49:29 +0000

> NB Offlist

Sigh.

---

From: Watson Ladd <[email-masked]>
Date: Tue, 29 Oct 2019 23:37:15 -0700

> The root server operators publish statistics on the traffic they get.
Links for some of their data can be found at https://root-servers.org.
>
> The anycast cluster for a.root-servers.net alone currently handles
upwards of 8B queries/day - roughly 100,000 queries/second. That’s steady
state. The numbers would go *far* higher than that during a Mirai-style
DDoS attack.
>
> It’s going to be a challenge to get authoritative servers handling those
sorts of query levels to support DoT (over TCP?). FWIW solving the
non-trivial operational and engineering issues will be the easy bit.
Solving the layer-9 issues will be harder. I expect that also holds for DoT
support at authoritative servers for important TLDs or the DNS hosting
platforms from the likes of Akamai, Dyn, UltraDNS, etc that handle very
high query rates.
>
> I suppose someone could ask RS SAC* for their opinion on deploying DoT at
the root. And having lit the blue touchpaper, I will now run away at great
speed to watch the ensuing firework display. :-)

The root zone is data: whether one distributes it via DoT, DoH, IPv6, or
carrier pigeon is irrelevant to the policies that goven what's in it. And
furthermore none of the network engineering issues raised against DoH apply
to recursive to authoritative.

We absolutely can engineer reliable anycast clusters to handle 100,000
queries a second. That's only 100 cores if each core can do 1000 queries a
second.

Akamai handles a substantially greater  volume of considerably more
expensive HTTPS traffic: the DNS queries are part of the HTTPS.

Encryption at the root is very possible.

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Alexander Mayrhofer <[email-masked]>
Date: Wed, 30 Oct 2019 08:40:58 +0100

Brian,

sorry, i haven’t yet posted the link to the list. The Repo is here:

https://github.com/alex-nicat/ietf-dprive-phase2-requirements

If anybody is in desperate need of elevated permissions on the repo, please let me know ;)

best,
Alex

Von: dns-privacy <[email-masked]> Im Auftrag von Brian Dickson
Gesendet: Dienstag, 29. Oktober 2019 19:51
An: Brian Haberman <[email-masked]>
Cc: [email-masked]
Betreff: Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Brian Dickson

On Fri, Oct 25, 2019 at 8:04 AM Brian Haberman <[email-masked]<mailto:[email-masked]>> wrote:
Hi Paul,

Brian

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

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 30 Oct 2019 07:49:12 -0500

Moin!

> queries a second. That's only 100 cores if each core can do 1000 queries a
We can and I don’t think Jim questioned that it is technically possible. But
someone has to pay for it and there are layer 9 problems. At some parts of
the DNS infrastructure the margins are thin and increasing your server load
or server foot print for ADoT might be the difference between making a profit
or a loss.

> expensive HTTPS traffic: the DNS queries are part of the HTTPS.
That is true, but we also have way more servers for HTTPS then for DNS, and
while I don’t want to see DNS traffic inside the same channel that delivers
content for various reason that for sure won’t happen with ADoT as we are
talking about a resolver and not and end client issuing the queries.

> Encryption at the root is very possible.
It for sure is, but it’s not as easy and I see the root probably being one
of the latest adopters of ADoT. In general that does not matter. We have
to design a protocol first and then maybe look at the special cases some
part of the tree might have.

So long
-Ralf
—--
Ralf Weber

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Oct 2019 09:10:20 -0400

> On Oct 29, 2019, at 20:44, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> 
> 
> 
> 
> My understanding is that one has no choice but to trust the parent zone, even with DNSSEC. 

One can limit the trust severely, which is what https://datatracker.ietf.org/doc/draft-pwouters-powerbind/ does.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Oct 2019 13:51:49 +0000

Some miscellaneous thoughts vaguely related to the discussion ...

## nameserver hostnames in certificates

It's not uncommon for zones to use in-bailiwick aliases for their
nameservers, which avoids transitive configuration dependencies and speeds
up resolution because the resolver gets glue with the referral rather than
having to chase down server addresses.

(see discussion of gluelessness on https://cr.yp.to/djbdns/notes.html)

This is obviously problematic for using hostname authentication. I suppose
a server could provide its IP address(es) and official hostnames in its
cert to allow either for authentication...

## third-party secondary servers

If the ADoT status is in the delegation (special DS records, special NS
records) then that implies a nasty co-ordination cost to any changes.

## glueful bootstrapping

If we rely on TLSA records at the nameserver's hostname then there's a fun
bootstrapping problem for in-bailiwick delegations. If a resolver queries
for the TLSA records in the clear then they'll leak the zone name; if it
speculatively tries TLS then it might be really slow waiting for timeouts.

## reverse dns bootstrapping

If the resolver looks for TLSA records in the reverse DNS there's a fun
case where it has a referral for (say) example.com with glue for
ns1.example.com in 192.0.2.1, but then it finds that ns1.example.com is
also a server for 2.0.192.in-addr.arpa. The resolver needs to be able to
re-use the forward DNS glue to get to the reverse DNS zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Great Orme Head to the Mull of Galloway: East or southeast 4 to 6. Smooth or
slight, occasionally moderate in west. Fair. Good.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:09:53 +0000

Great detailed feedback, thanks. Have flagged in https://github.com/alex-nicat/ietf-dprive-phase2-requirements/issues/11

From: Brian Dickson <[email-masked]>
Date: Tuesday, October 29, 2019 at 12:37 AM
To: Alexander Mayrhofer <[email-masked]>
Cc: "Livingood, Jason" <[email-masked]>, Brian Haberman <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29

Hi, everyone interested in ADoT,
I'm planning on being on the call, although given the early hour for me I can't be sure I'll be on my game as much as usual...

In the interests of getting all the ideas I have after reading the -00 draft, I thought I'd send them to the list, and maybe they can be discussed on the call, time permitting.

Simple notion up front: add an EDNS flag or OPT code to signal ADoT support (or a bit field of all the supported transport types) on a given IP (analogous to the RA flag), and possibly include the canonical name(s) of the server at that IP, if the query include EDNS. This limits downgrades to on-path adversaries who block port 853 and modify port 53 traffic. Maybe SIG(0) or TSIG can further prevent downgrades by on-path attackers who would modify UDP/TCP port 53?

Certificates for DoT and DoH should really be DANE/TLSA entries. We're literally talking DNS here, so it would be particularly shortsighted not to standardize on this. It also potentially decouples from any hard dependency on particular CA support matrix, notwithstanding that the authoritative server might be using a CA-issued certificate. Having the ability to validate without needing to unilaterally trust some particular set of CAs is a feature not a bug.

State exhaustion protection mechanism, optionally use TCP cookies during handshake, regardless of TLS or not. This limits the TCP impact of needing established connections to do the TLS stuff to legitimate TCP connections only. Servers can limit the number of connections doing TLS handshakes, and prioritize those. The, use of aggressive timers on those prioritized connections protects against deliberate DOS via "slow transaction" attacks. Handshake-complete connections can be resumed, so making them lower priority and having aggressive connection dropping on those has comparatively low impact (since session resumption is cheaper than redoing the handshake). Experimentation is needed to establish recommendations on all the appropriate values (timeouts, number of sessions to support in each state, etc.)

The rest of the ideas mostly relate to the question "when is using DoT really optional, vs strongly desirable?".

I have a few suggestions along that line, as well as a few additional observations.

First, there is a strong correlation between the first time any client queries a given name, the visibility of the corresponding R2A query (presuming no ADoT), and the subsequent client data traffic (even with HTTPS).
The R2A (recursive to authoritative) query is a strong indicator that the name isn't cached (and may never have been cached).
This correlation may not be that important per se, but identifying it as somewhat distinctive means there's a reason to potentially look at the implications of that (from the perspective of ADoT being "strongly desirable").

In contrast, very popular domain names (and qtypes) are likely to be heavily served from the cache. If cache refresh (what was once identified in the HAMMER draft) is done for popular cache entries, there would no longer be any identifiable query triggering the R2A lookup, and in particular no timing side channel for identifying even a single DNS client.

What I'm suggesting is, using ADoT predominantly (or even exclusively) for "cold cache" lookups, and doing "cache refresh" lookups without ADoT, is one way to minimize the TLS overhead, which incurs a cost on the authority server (mostly CPU) and a penalty on the recursive (mostly latency, and maybe some CPU). Refresh without TLS would have lower latency, IMHO.

IMHO, the same rationale for "cold cache" also applies to "ECS" (EDNS client subnet). First instance (of a particular ECS parameter value), use ADoT; refresh, ADoT is optional.

The other question (observation?) is that ADoT is a poor substitute for DNSSEC. I.e. unsigned zones might seem like attractive reasons to force DoT for transport, but doing so would basically amount to "security theater". It would also discourage, rather than encourage, use of DNSSEC validation. It would be justifiable for an authority operator to respond "REFUSED" for ADoT queries doing "refresh cache" queries on unsigned domains, at least during periods of heavy load. Or maybe some new error code or EDE to signal "retry on non-TLS connections".

It remains an open (and perhaps interesting) question of the relative overhead of DNSSEC validation when compared with TLS transport. It might be interesting to compare those based on crypto algorithms (for negotiated TLS connections, and for DNSSEC zones), and based on various TTL values.

Having validation of DNSSEC signed zones, on popular domains being refreshed without ADoT, would potentially be the "sweet spot" for security and privacy. Security, by having cryptographically signed zone data, and privacy by the aforementioned "cold cache" and "cache refresh" distinction.

This might be where the EDNS signaling available directly between the recursive and authoritative, would allow the authoritative server to make the informed decision to reply with UDP instead of over the ADoT connection, if/when it experiences significantly increased load. The recursive could always try to use ADoT, but get signal(s) from the authority server to limit ADoT to "cold cache" queries only in response to load problems.

Finally, I'd like to announce the following:
GoDaddy now has four ADoT servers in its OTE environment.
They are ns01/ns02, and pdns01/pdns02 in ote.domaincontrol.com<https://protect2.fireeye.com/url?k=dcb1e45753111730.dcb1c3e3-d1a47abc06098c89&u=http://ote.domaincontrol.com>, with domains dnsczar.com<https://protect2.fireeye.com/url?k=f4b2d6351b8051c8.f4b2f181-57184a53d0f219a2&u=http://dnsczar.com> and sheldns.com<http://sheldns.com> on those respective nameserver pairs.
The TLS certificate names match the NS names for those domains.
The test domains are also DNSSEC signed.
(The domaincontrol.com<http://domaincontrol.com> zone is not yet signed, so no DANE/TLSA for the certs just yet.)

Please feel free to test against those domains, and feedback on that testing is being actively solicited. Send feedback to [email-masked]<mailto:[email-masked]> please.

All credit for the DoT goes to my colleague Michael Sheldon (as do all the GoDaddy DNS software kudos.)
We are supported by our excellent ops team including Brian King, Jason Lynch, Frank Even, and Tyler Stanton.

Brian Dickson

On Mon, Oct 28, 2019 at 3:24 AM Alexander Mayrhofer <[email-masked]<mailto:[email-masked]>> wrote:
I've just posted the -00 individual submission version:

best,
Alex

On Fri, Oct 25, 2019 at 8:59 PM Livingood, Jason
<[email-masked]<mailto:[email-masked]>> wrote:
> On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
>
>     Hi Paul,
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:18:59 +0000

From my perspective it didn't seem that query privacy meant only encryption; there may be steps that can be privacy-protective that can be taken independently of or before encryption (ergo QNAME min). That seems a key question for the WG --> is query privacy limited to encryption or are there addition things or alternative things that can be done?

In addition, the notion of addressing potential differences between RSOs, TLDs and SLDs grew from the realization that each of these are usually distinct groups of operators, may have different requirements or operational goals/concerns, and will likely implement on different timeframes. But this is simply a matter of opinion right now - let’s maybe see how it looks as we amend the requirements based on the call & mailing list and see how things shape up.

Jason

On 10/29/19, 10:20 AM, "dns-privacy on behalf of Paul Hoffman" <[email-masked] on behalf of [email-masked]> wrote:

    --Paul Hoffman

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 30 Oct 2019 18:40:21 +0000

I agree that this is not a technical issue of scaling the root; that quantity of queries per day and second is not a big problem. Rather, as you note, it is a layer-9 issue. But I don't think we should constrain our requirements development & protocol design because of this. Ultimately root operators and others will need to make independent assessments of cost/benefit and it's not unheard of for communities in ICANN to initiate the different policy development processes in order to change pricing/margin/contract stuff to accommodate new requirements.

On 10/29/19, 11:30 PM, "dns-privacy on behalf of Jim Reid" <[email-masked] on behalf of [email-masked]> wrote:

    > Why? Do we have estimates of the load level here as compared to (say) Quad9 or 1.1.1.1?

    The root server operators publish statistics on the traffic they get. Links for some of their data can be found at https://protect2.fireeye.com/url?k=2afc0159bfd08024.2afc26ed-cd00c20c720e6f6a&u=https://root-servers.org.

---

From: "John Levine" <[email-masked]>
Date: 30 Oct 2019 21:21:41 -0400

>Encryption at the root is very possible.

Indeed, but that's not the same question as whether it's a good idea.

It is my strong impression that whatever problem you would solve with
DoT to the root can also be solved using a local copy of the root,
which has the practical advantage that you can do it right now.

Also, depending how we decide that a name server signals that it
supports DoT (or perhaps a parent gives a hint with the referral) it
might make life a lot easier if the signals don't have to start all
the way at the top.

Let's put this in the pile of things to think about later.

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Thu, 31 Oct 2019 17:11:45 +0000

> On 30 Oct 2019, at 18:40, Livingood, Jason <[email-masked]> wrote:
> 
> I agree that this is not a technical issue of scaling the root; that quantity of queries per day and second is not a big problem. Rather, as you note, it is a layer-9 issue. But I don't think we should constrain our requirements development & protocol design because of this. 

In principle, I agree with you. Though in practice, I'm questioning if it makes sense to work on ADoT unless there's a strong likelihood it will get mainstream deployment and adoption. [What's the point of producing something that won't see widespread use?] And surely if there's going to be ongoing protocol design work, that needs to take account of the concerns of those who run busy authoritative servers? AFAICT apart from a recent ID from Verisign, they have not been part of the discussion so far.

---

From: Jim Reid <[email-masked]>
Date: Thu, 31 Oct 2019 19:06:36 +0000

> On 30 Oct 2019, at 06:37, Watson Ladd <[email-masked]> wrote:
> 
> The root zone is data: whether one distributes it via DoT, DoH, IPv6, or carrier pigeon is irrelevant to the policies that goven what's in it. 

I agree. But that's orthogonal to what I thought we were discussing.

There are gazillions of layer-9+ problems around the introduction of new or different distribution mechanisms at the root for serving root zone data. Not least of these are the interminable ICANN consultations that inevitably have to take place for anything remotely related to the root.

Some of those problems will also apply to ADoT deployment at "busy" TLDs and their DNS service providers.

---

From: Jim Reid <[email-masked]>
Date: Thu, 31 Oct 2019 19:07:12 +0000

> On 31 Oct 2019, at 01:21, John Levine <[email-masked]> wrote:
> 

+1

> ...

+1 to that too.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 31 Oct 2019 14:16:52 -0500

On Thu, Oct 31, 2019 at 12:11 PM Jim Reid <[email-masked]> wrote:

> > I agree that this is not a technical issue of scaling the root; that
> quantity of queries per day and second is not a big problem. Rather, as you
> note, it is a layer-9 issue. But I don't think we should constrain our
> requirements development & protocol design because of this.
>
> In principle, I agree with you. Though in practice, I'm questioning if it
> makes sense to work on ADoT unless there's a strong likelihood it will get
> mainstream deployment and adoption. [What's the point of producing
> something that won't see widespread use?] And surely if there's going to be
> ongoing protocol design work, that needs to take account of the concerns of
> those who run busy authoritative servers? AFAICT apart from a recent ID
> from Verisign, they have not been part of the discussion so far.
>
>
I think there will be both interest and deployment, sufficient to justify
the effort.

IMHO, including the ability for authority operators to signal support, may
be sufficient to address the concerns about the root servers, including
that they may have different levels of interest in supporting DoT.

E.g. Having a well-defined record at or under the NS name that indicates
support for transport protocols would enable each root-server.net instance
to signal whether DoT queries might be answered.

That itself might crack open another can of worms: DNSSEC signing of
root-servers.net, including possible naming choices for the root servers
(qv related investigative work that was being done by the RSSAC Caucus.)

One idea that was not considered previously, that just occurred to me: have
root-servers.net be DNSSEC signed, but without a secure delegation. It
would be an island of security that could be optionally be securely
accessible via adding a new trust anchor, specifically if/when a particular
resolver wishes to use ADoT to authority servers. I believe it would not
impact the priming responses.

(Also, I think the ADoT requirements should include an assumption that ADoT
is not supported unless the nameserver name explicitly signals such at or
under the nameserver's name.)

Brian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 31 Oct 2019 12:27:13 -0700

On Thu, Oct 31, 2019 at 12:06 PM Jim Reid <[email-masked]> wrote:

>
> There are gazillions of layer-9+ problems around the introduction of new
> or different distribution mechanisms at the root for serving root zone
> data. Not least of these are the interminable ICANN consultations that
> inevitably have to take place for anything remotely related to the root.
>
I think the point John Levine was making earlier relates to this, though.
If the root zone is signed, it is small enough to keep a copy locally in
any reasonable cache.  That means many caching resolvers can avoid using
DoT on queries routed to the root by using AXFR instead,  to the servers
mentioned in https://www.dns.icann.org/services/axfr/ or similar servers
hosted elsewhere.  Asking that those AXFR-suitable servers support DoT
seems a much more tractable proposition and it results in the right thing.

I may have misunderstood John, of course, but that's the point of what I
understood him to be saying.

regards,

Ted

---

From: Warren Kumari <[email-masked]>
Date: Thu, 31 Oct 2019 15:35:29 -0400

On Thu, Oct 31, 2019 at 3:27 PM Ted Hardie <[email-masked]> wrote:
> I think the point John Levine was making earlier relates to this, though.  If the root zone is signed, it is small enough to keep a copy locally in any reasonable cache.  That means many caching resolvers can avoid using DoT on queries routed to the root by using AXFR instead,  to the servers mentioned in https://www.dns.icann.org/services/axfr/ or similar servers hosted elsewhere.

See: https://datatracker.ietf.org/doc/draft-ietf-dnsop-7706bis/ and
RFC7706 for details on how....
draft-ietf-dnsop-7706bis is in WGLC, so that's the one people should read).

Thank you Ted, for queuing this up so nicely!
W

> Asking that those AXFR-suitable servers support DoT seems a much more tractable proposition and it results in the right thing.
>
> I may have misunderstood John, of course, but that's the point of what I understood him to be saying.
>
> regards,
>
> Ted

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2019 15:38:59 -0400

>I think there will be both interest and deployment, sufficient to justify

I hope so, but some actual comments from large DNS operators would be welcome.

>root-servers.net be DNSSEC signed, but without a secure delegation. ...

Do any DNS resolvers use root-servers.net?  I thought they took an IP
address from the local cache file and then an NS query to get the
current root set.  This doesn't strike me as a problem we urgently
need to solve.

>under the nameserver's name.)

I'm not yet prepared to rule out approaches where the parent sends the signal.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2019 15:43:29 -0400

>understood him to be saying.

Pretty much.

The root is an unusual zone in that it is small and unlikely ever to
be huge, it is easy to AXFR without prior arrangement, and its
management is subject to a thick layer of politics.  Since it is
signed you can get its contents from anywhere convenient.

Many of us already treat it as a special case by running a local
mirror, so I don't think it's a big deal if our ADoT techniques only
work starting at 2LDs.

R's,
John

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 31 Oct 2019 15:49:00 -0400

On Wed, Oct 30, 2019 at 2:37 AM Watson Ladd <[email-masked]> wrote:

> carrier pigeon is irrelevant to the policies that goven what's in it.
>

That is arguably true, but I think we are having this discussion primarily
because of RFC 4035 Section 2.2:

   the NS RRsets that appear at delegation points (that is, the NS
   RRsets in the parent zone that delegate the name to the child zone's
   name servers) MUST NOT be signed

Some of the proposals being discussed here would bootstrap ADoT from the
contents of the NS record at the delegation point.  The problem is that
this record is not signed.  As a result, an attacker could inject a forged
version of these records into a recursive cache, breaking ADoT to the child.

The ideas floated here about ADoT to the root are not, in my view, about
privacy (directly).  They're about using ADoT to protect the integrity of
(currently) unsigned data in the root zone.

An alternative solution is to get ADoT bootstrap info from the child zone,
where it could be signed, before making a query that reveals the next
label.  This could work, but at the cost of an extra roundtrip.  (How often
this latency penalty applies depends on the details of the construction.)

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 31 Oct 2019 20:31:59 +0000

Hiya,

On 31/10/2019 19:49, Ben Schwartz wrote:
> An alternative solution 

I wonder if we'd be better off here if we encourage people
to do and document experiments before we try to select one
(or >1) approach?

I figure the trade-offs are complex enough that a round of
people pruning possibilities themselves might be better
before we try pick which answers are worth standardising.

E.g., maybe run an initial stage of this as a competition
like thing where (on some date) people need to turn up
and describe their approach and how they got on when doing
experiments with that?

Cheers,
S.

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2019 17:12:22 -0400

>this latency penalty applies depends on the details of the construction.)

Thinking about it a little more, I think it is likely that there will
be islands of ADoT sort of like there used to be islands of DNSSEC.
For example, I expect the people on this list are likely to deploy
ADoT long before some of the 2LD's above them. Moreover, all of the
problems about getting your DS into the zone above would apply to
getting your ADoT signal there.  Even with the cost of an extra lookup
it's probably going to work better to have each island describe itself
so you don't need an unbroken chain of ADoT from the root.

R's,
John

PS: Yes, this is the opposite of what I said yesterday.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 31 Oct 2019 16:40:44 -0500

On Thu, Oct 31, 2019 at 4:12 PM John Levine <[email-masked]> wrote:

> In article <
> [email-masked]> you
> write:

IMNSHO, ADoT at the leaf + QNAME minimization is all that is required for
privacy.
I.e. No need for ADoT anywhere other than at the leaf zone's name server
(whose NS name might not be in-bailiwick, FYI).

Brian

---

From: "John R Levine" <[email-masked]>
Date: 31 Oct 2019 17:53:28 -0400

> (whose NS name might not be in-bailiwick, FYI).

I dunno, I can think of some 2LD queries that might leak interesting 
stuff.  Does it really matter which subdomain of mega-xxx-babes.com I'm 
looking at?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 31 Oct 2019 17:37:25 -0700

On Thu, Oct 31, 2019 at 2:41 PM Brian Dickson <[email-masked]>
wrote:

>> [email-masked]
>> <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail..gmail.com>>
>> you write:
>> >this latency penalty applies depends on the details of the
>> construction..)
>>

Hmm.... I think that's only true if you are assuming that the NS record for
the leaf is DNSSEC secured, but that doesn't seem like a safe assumption.

-Ekr

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 1 Nov 2019 07:56:10 +0100

On 11/1/19 1:37 AM, Eric Rescorla wrote:
> Hmm..... I think that's only true if you are assuming that the NS
> record for the leaf is DNSSEC secured, but that doesn't seem like a
> safe assumption.

Generally speaking, I believe it's fine to add assumptions about DNSSEC
validation, if that makes the ADoT protocol "better" in some way.  (and
I expect it will)  It seems that DNSSEC will be much easier than this
new stuff.

By the way, I'm personally not yet 100% convinced by TLS and might e.g.
add QUIC into consideration.  At least from protocol perspective, as I'm
not looking forward to adding yet another protocol to resolver
implementations.  Still, towards resolvers you almost always have very
few connections, so handshakes amortize easily; towards authoritatives
the situation is quite different, assuming we don't gravitate towards a
small number of huge CDNs (for DNS)... which would bring back arguments
from discussions around the privacy of securely tunneling all your
queries to one CDN. 

Note that in any case, connection-based protocols (and adding
complexity) will increase relative advantages of larger providers, but
I'd personally prefer to minimize this effect.  (Though perhaps that's
mainly due to not being affiliated with a large one.)

--Vladimir