Subject: Re: [dns-privacy] Intermediate proposal (what I was saying at the mic)

From: "Martin Thomson" <[email-masked]>
Date: Mon, 02 Aug 2021 14:21:59 +1000

On Fri, Jul 30, 2021, at 06:08, Eric Rescorla wrote:
> - Recursives can attempt to connect to any authoritative by probing
>   with DoT/DoQ [0]. In this case, they should cleanly fall back to
>   Do53 on connect failure and not validate the credential (whether
>   WebPKI or DANE) This allows authoritatives to just turn on TLS
>   without risk.

I assume that your MUST NOT validate here only exists because of the combination of:

1.  Us not being able to decide between Web PKI and DANE; and

2.  The potential for an unauthenticated mode.

If we decided on a single answer for the first and in the negative for the second, would that make authentication viable?  Or is the opportunism a feature?

---

From: Christian Huitema <[email-masked]>
Date: Sun, 1 Aug 2021 23:22:15 -0700

> If we decided on a single answer for the first and in the negative for the second, would that make authentication viable?  Or is the opportunism a feature?

I am torn on the PKI vs DANE issue. I understand the simplicity of using 
Let's encrypt or similar and getting an X.509 certificate backed by 
proof of ownership of the domain name. But I am also very concerned that 
this introduces a circular dependency. Allowing for DANE breaks that 
dependency when DNSSEC is available, which is why I would like 
authentication to allow both. If the server can prove its identity using 
either DANE or PKI, the client is probably fine.

And given the simplicity of getting PKI, I don't quite see the point of 
an unauthenticated mode. It does not ease the deployment much, and it 
paints a thick MITM target. I would rather fall back to Do53 than to 
unauthenticated DoT or DoQ.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Aug 2021 06:10:39 -0700

> 1.  Us not being able to decide between Web PKI and DANE; and

Largely, though it also allows for incremental rollout and a new auth
mechanism.

>
> If we decided on a single answer for the first and in the negative for the
> second, would that make authentication viable?  Or is the opportunism a
> feature?
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 2 Aug 2021 14:22:45 +0100

Hiya,

On 02/08/2021 05:21, Martin Thomson wrote:
> If we decided on a single answer for the first and in the negative
> for the second, would that make authentication viable? 

IMO we ought not just "decide" on most of the tricky ADoX
issues but we should rather document the options sufficient
to allow people to do experiments and then wait and see how
those experiments go. I'd say a stable I-D is probably
enough documentation to allow for experiments and I'd hope
such experiments could be done in 6-12 months. I'd expect
we might still be left with a few tricky issues, but that
a number of those (where we might make wrong choices now)
would be resolved once people try 'em out.

So my suggestion is to review the I-Ds we have with a view
to figuring out what's missing that's needed to allow such
experiments, fix that and then "park" those I-Ds 'till we
get results. That could be similar to how drafts are declared
to be "interop drafts" in other WGs or could be a WGLC-like
process.

If we decided to try go that way, I'd be happy to try help
get some such experiment going.

Cheers,
S.

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Aug 2021 16:34:48 -0400

In my view,

1. We should provide guidance on how to do unauthenticated DoT/Q using
default-port probing, like we used to have in
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-opportunistic-adotq-00
.

2. Publishing a SVCB record should indicate support for authenticated
encryption.  Nameservers that don't support authenticated encryption can
offer opportunistic encryption based on default-port probing.

3. We should allow nameservers to indicate support for authentication via
common PKI, DANE, or both.

4. SVCB and TLSA records are a firm promise, but resolver behavior is
always up to the operator.  They can choose whether to "fail closed", skip
authentication, fall back to UDP, etc.

On Mon, Aug 2, 2021 at 9:11 AM Eric Rescorla <[email-masked]> wrote:

>> If we decided on a single answer for the first and in the negative for
>> the second, would that make authentication viable?  Or is the opportunism a
>> feature?
>>

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Aug 2021 20:55:11 +0000

On Aug 3, 2021, at 1:34 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> In my view,
> 
> 1. We should provide guidance on how to do unauthenticated DoT/Q using default-port probing, like we used to have in https://datatracker.ietf.org/doc/html/draft-ietf-dprive-opportunistic-adotq-00.
> 
> 2. Publishing a SVCB record should indicate support for authenticated encryption.  Nameservers that don't support authenticated encryption can offer opportunistic encryption based on default-port probing.
> 
> 3. We should allow nameservers to indicate support for authentication via common PKI, DANE, or both.
> 
> 4. SVCB and TLSA records are a firm promise, but resolver behavior is always up to the operator.  They can choose whether to "fail closed", skip authentication, fall back to UDP, etc.

If the WG is going to go to DS in the parent to have a signed signaling response, it would make sense that the signal in the child have an identical format. If we go with that, I'd rather see CDS be used in the child instead of SVCB.

I like using #4 as a way to bridge the two use cases (well, the stated unauthenticated use case and whatever fully-authenticated use case eventually gets published). That way, resolvers that have the unauthenticated use case have more reliable ways to get the signal, and also can get a signal for DoH.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Aug 2021 17:06:28 -0400

On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman <[email-masked]> wrote:

> If the WG is going to go to DS in the parent to have a signed signaling
> response, it would make sense that the signal in the child have an
> identical format. If we go with that, I'd rather see CDS be used in the
> child instead of SVCB.
>

I disagree.  CDS is explicitly a signal from the Child to the Parent.  It's
literally in the name of the RR type.  I would not want all the resolvers
in the world to be reading CDS records as part of the iterative resolution
process.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 3 Aug 2021 21:19:59 +0000

On Aug 3, 2021, at 2:06 PM, Ben Schwartz <[email-masked]> wrote:
> I disagree.  CDS is explicitly a signal from the Child to the Parent.  

Yes, exactly. This is the best way to get those DS records in the parent.

> It's literally in the name of the RR type.  I would not want all the resolvers in the world to be reading CDS records as part of the iterative resolution process.

Why is "all the resolvers in the world to be reading" an SVCB record better?

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Aug 2021 17:30:51 -0400

> Yes, exactly. This is the best way to get those DS records in the parent.

Quite possibly, yes, but far from the only way.  In fact, CDS record
support is not widely deployed at present.

> It's literally in the name of the RR type.  I would not want all the
> resolvers in the world to be reading CDS records as part of the iterative
> resolution process.
>

In the parent, our RR type choices are constrained by a slow-moving
ecosystem, so we may have to reuse the DS RR type in some fashion.  In the
child, we don't have this problem, so we can use proper RR types with
purpose-designed semantics, zone file representation, and wire format.

I'll put together a more detailed proposal and then we can argue about this
some more.

---

From: "libor.peltan" <[email-masked]>
Date: Wed, 4 Aug 2021 09:56:14 +0200

I think that if we decide to employ DS the new way to signal the desired 
transport protocol, the CDS->DS mechanism might still be used to 
"upload" those DSs to the parent (however, it's not allowed by current 
RFCs, since CDNSKEY is required whenever CDS exists). (I don't conclude 
if this has any effect of usefulness of SVCB at the child apex or just 
permanent CDS there.)

Libor

Dne 03. 08. 21 v 23:30 Ben Schwartz napsal(a):
>
>
> On Tue, Aug 3, 2021 at 5:20 PM Paul Hoffman <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On Aug 3, 2021, at 2:06 PM, Ben Schwartz <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >
>     > On Tue, Aug 3, 2021 at 4:55 PM Paul Hoffman
>     <[email-masked] <mailto:[email-masked]>> wrote:
>     >> If the WG is going to go to DS in the parent to have a signed
>     signaling response, it would make sense that the signal in the
>     child have an identical format. If we go with that, I'd rather see
>     CDS be used in the child instead of SVCB.
>     >>
>     > It's literally in the name of the RR type.  I would not want all
>     the resolvers in the world to be reading CDS records as part of
>     the iterative resolution process.
>
> ecosystem, so we may have to reuse the DS RR type in some fashion.  In 
> the child, we don't have this problem, so we can use proper RR types 
> with purpose-designed semantics, zone file representation, and wire 
> format.
>
> I'll put together a more detailed proposal and then we can argue about 
> this some more.
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 5 Aug 2021 11:06:12 -0700

On Tue, Aug 3, 2021 at 1:55 PM Paul Hoffman <[email-masked]> wrote:

> I like using #4 as a way to bridge the two use cases (well, the stated
> unauthenticated use case and whatever fully-authenticated use case
> eventually gets published). That way, resolvers that have the
> unauthenticated use case have more reliable ways to get the signal, and
> also can get a signal for DoH.
>

Some (IMNSHO) important observations, and recommendation for direction on
these:

   - SVCB in the name server name's zone is where the signalling belongs
   (on what transports are supported, per NS name, as well as authenticated or
   not, etc)
   - TTL on DS is controlled by the parent zone, and may not be appropriate
   for risky changes, thus not a good place for signalling
   - DS is a good place to protect the glue (NS records themselves, plus
   glue A and AAAA records) - in fact, it is the only viable solution for that
      - DS for the NS needs to scale according the NS RDATA, not the owner
      names, so the DS per zone should not include the zone name (too
esoteric to
      discuss/debate this point, I think)
   - Signaling transport should be SHOULD, just to avoid port probing.
      - Opportunistic authentication is different from opportunistic period
      - It is better to signal transport and whether it is authenticated
      (in once place, the SVCB record)
   - The parent DS is per zone, not per name server, so that is NOT where
   transport/opportunistic signaling belongs (e.g. changing those MUST NOT be
   per zone)
   - There is a separate DS for the name server's names' zone, of course...
      - That is where the glue A/AAAA records can be added to protect the
      resolution needed for querying for SVCB records
   - I don't think there is any reason to specifically support unsigned
   name server name zones
      - You need signed data to protect the information needed to get to TLS
      - It's integrity, not privacy, that is needed at this step
      - The first query to the NS name's zone cannot be TLS yet, because
      the info for TLS isn't available yet (catch 22)
   - TLSA allows signaling of WebPKI as an optional required validation
   over the certificate in the TLSA record (types 0/1 vs 2/3 IIRC).
      - Optional validation != optional WebPKI
      - You can have a signal that says "mandatory validation using TLSA
      but not WebPKI"
      - That signal could instead be, "mandatory validation using both TLSA
      and WebPKI"
      - Both are downgrade resistant
   - SVCB would signal DNS operators intent for failure mode
      - E.g. opportunistic (fail to fallback) vs mandatory (fail hard),
      subject to resolver's own policies (which could ignore DNS operator's
      signal)
   - If you require a signed zone anyway, and are going to do TLS (that's
   what we are discussing), then *requiring* TLSA records (with or without
   WebPKI) is a very easy thing to justify
      - Reminder: just because type 2/3 records don't require WebPKI
      validation, does not mean you can't use CA issued certs for those
      - It just means the validation avoids having to do WebPKI stuff.
      - DNSSEC signatures protect the cert fingerprint (EE or parental) in
      all cases
   - TL;DR: registrant zone gets DS with protection over NS RDATA; name
   server name delegation is similarly protected; name server name resolution
   at some point depends on glue A/AAAA which also get DS protection; name
   server name has SVCB and TLSA records; SVCB signals opportunistic or not;
   TLS validation via WebPKI is signaled via TLSA; deployments and roll-back
   are handled strictly in the name server name's zone (including use of
   appropriate TTL values during deployment/rollback)

Resolvers can still work with this even if they don't do DNSSEC validation.
They do lose downgrade protection, but can still resolve fine.

Resolvers that do DNSSEC validation are protected against downgrade, IFF
the DNS operator has elected to signal hard failure. This protects against
MITM on both DNS and transport (TLS).

Brian

---

From: Brian Haberman <[email-masked]>
Date: Tue, 17 Aug 2021 08:16:53 -0400

All,
     I want to start working through the details of what Stephen is
proposing below; beginning to do operational experiments to determine
which approach, or approaches, may be viable in the long term. To carry
out such experiments, I believe we need the following:

1. A stable I-D for an approach to providing privacy between recursive
resolvers and authoritative servers,

2. An implementation of the stable I-D in a recursive resolver and in an
authoritative server implementation,

3. At least one authoritative server operator willing to deploy the
experimental implementation,

4. At least one recursive resolver operator willing to deploy the
experimental implementation,

5. An agreed upon set of metrics to assess the operational behavior of
the approach,

Is there a major item missing from the list above? Other aspects of
carrying out such an experiment?

Are there any volunteers to start working on details of such an experiment?

Regards,
Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Aug 2021 13:47:20 +0100

Hiya,

> resolvers and authoritative servers,

More than one I-D seems likely and is fine I reckon.

> authoritative server implementation,

IIUC, that exists?

> 5. An agreed upon set of metrics to assess the operational behavior of

Not sure a final/agreed version of that's needed before
someone starts to run an experiment. Nice to have it of
course but I suspect initial experiments will throw up
bits of data we'd not considered (e.g. maybe relating to
the diversity of partnerships that authoritative servers
have and how those affect partial rollout).

> Are there any volunteers to start working on details of such an experiment?

I'm game. (But not this week, taking a few days away:-)

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 24 Aug 2021 14:23:47 -0400

>    (on what transports are supported, per NS name, as well as authenticated or

I'm agnostic about the mechanism specifically, but i am curious as to
the rationale for the signalling being per-nameserver name.

The plausible options for where to signal, as i see it, are:

 a) signal per authoritative zone ("per zone") [excluding delegated subzones?]
 b) signal per authoritative nameserver name ("per NS name")
 c) signal per authoritative namserver IP address ("per IP")

I think the *information* we're looking to signal, however we do it,
consists of:

 0) what forms of encrypted transport are available
 1) what forms of authentication are available (including what
    public keys to expect?)
 2) when and how to report problems with encrypted+authenticated
    transport
 3) whether a recursor should hard-fail if the signalled
    authenticated+encrypted transport is not accessible (or, viewed
    as the inverse, whether fallback to port 53 is acceptable)

It's possible that these four different pieces of data belong to
different scopes.

For example, it's possible that 0 and 1 should be signaled "per NS name"
but 2 and 3 should be signaled "per zone".

Consider the situation where the zone administrator is different from
the NS operator.

Semantically, as a zone administrator, i think i would *want* (2) and
(3) to be "per zone", *not* "per NS name": i would want hardfail to be a
choice *I* make, not the NS operator, and if it's going to be a choice I
make, it needs to be a choice I can choose to gather data about, which
means i need to be able to control reporting.  I can see why (0) and (1)
might make more sense as "per NS name" operationally -- the NS operator
knows what services they can deploy and what authentication mechanisms
they can provide.

Some scenarios for the group to consider:

  I. Consider the case where NS record N1 for zone Z1 points to the same
     IP address X as NS record N2 for zone Z2.  A recursor knows that it
     has had a recent successful encrypted+authenticated connection to X
     as N1 (resolving a name in Z1), but is now looking up a name in
     zone Z2 via N2, and no signalling is available for Z2 or N2.  What
     should the recursor do?  In particular, should it go ahead and use
     the known-good enc+auth connection to X as N1, ignoring the fact
     that it's supposed to be accessed as N2?  should it try an
     encrypted connection to X as N2 but accept if the authentication as
     N2 fails?  Should it just make a cleartext connection to port 53
     instead?

 II. Consider the same circumstance as (I), but where signalling is
     available for N2 that says "DoQ with DANE authentication is
     available; do not fall back to cleartext transport (that is,
     hardfail)".  If authentication fails for N2, what should the
     recursor do?

III. Consider the same circumstance as (II), but where the signalling is
     available for Z2 instead of N2.  If authentication fails for N2,
     what should the recursor do?

 IV. What if the signalling does not indicate hardfail?

  V. What if the signal for Z2 or N2 says DoQ is indicated, but the
     recursor knows (by probing, or by experience) that DoT actually
     works?  What if it knows that DoT works for N1, but it fails to
     complete a DoQ connection to N2?

 VI. What if N2 itself resolves to multiple IP addresses, not merely X?
     Should the resolver treat those different addresses differently
     (e.g., should it prefer X where it knows some form of encrypted
     transport is available)?

There are a *lot* of moving parts here in terms of potential fallback
strategies and risks.  At a minimum, we have a multidimensional space
of:

 - types of transport
 - types of authentication
 - NS names
 - NS IP addresses
 - zones
 - whether to hardfail or not

and we haven't even touched the semantics or mechanics of reporting
problems (i.e., following a model like TLSRPT).

I'm worried that this complexity makes it nearly impossible to analyze
fallback behavior in any reliable way. (not from a security
perspective -- fallback isn't going to offer many guarantees -- but from
an availability/efficiency perspective, how do we evaluate it and figure
out whether there are edge cases that will break nameservice resolution?)

Can we cut this problem into more managable pieces than our current
breakdown?  In particular, can we drop all mention of signalling from
draft-ietf-dprive-unauth-to-authoritative?  Or maybe we need a separate
draft to specify probing-specific, opportunistic behavior for the
recursor without worrying about signalling at all.  If we could do that,
that would be a baseline behavior, and we could specify rules for
signal-handling as a deviation from that baseline.

Note that if opportunistic probing is done to provide maximal protection
against a passive monitor with a minimum risk of breakage/delay, it
would be neither "per NS name" nor "per zone" but rather it would be
"per IP address".

                --dkg

---

From: Brian Dickson <[email-masked]>
Date: Wed, 25 Aug 2021 19:05:57 -0700

>  0) what forms of encrypted transport are available

I think what needs to be signaled, is what transports are available.
This could be traditional UDP/TCP, and/or DNS over TLS, and/or DNS over
QUIC, and/or any other transports.
Specifically, if the transport available is signaled as being "DNS over TLS
ONLY", that would be one way to prevent fallback.
Similarly, signaling "DoT or Do53", would be to explicitly signal that
fallback is permitted (in terms of what the zone admin and NS operator
offer).

Of course, whether a client (recursor) does fallback is a local policy
thing, if fallback is offered.
If fallback is not offered, then it is literally impossible to fall back.

> knows what services they can deploy and what authentication mechanisms

I see what you are saying here, and don't disagree. Or rather, what I am
getting at is, more than one NS name can exist for a given server and the
corresponding policy is tied to each specific name.
The zone admin would have control over which NS name is used,
hypothetically at least, and by way of picking the NS name(s), is able to
get per-zone behavior, while still having a scalable infrastructure (naming
scheme specifically).

There is a non-obvious benefit in using NS names for the attachment point
for policies (including transport, fall-back or fail-hard, etc.):  Multiple
names can point to the same IP address (IPv4 or IPv6).

If the NS operator chooses to do so, a suitable scheme can be used for
naming, that distinguishes "instances" of a given name server IP on the
basis of name.
Each of these instances can have its own policies, and those policies can
happily coexist.

Wildcards become your friend in this case, if a suitable naming scheme is
used, and a service binding (RRTYPE) is used so that no LEAFATTR values are
needed (e.g. _port._proto.NS_NAME).
Assuming a "dot" service binding were defined, which allowed for signaling
policies and supported transport(s), it would be quite scalable to group NS
names beneath a set of labels indicating policies, and using wildcards to
instantiate those policies.
(That's a lot of words, sorry. The example itself has way less in it.)
ns001.just-do53.example.net.   A IP_ADDR1
ns001.just-dot.example.net. A IP_ADDR1
ns001.dot-fallback.example.net. A IP_ADDR1
*.just-do53.example.net DOT 1 "." // service binding type, not alias type,
and use only default-ALPN which is DNS over UDP or TCP on port 53. The "."
binds this to the self-same name for the name used for the target.
*.just-dot.example.net DOT 1 "." no-default-alpn alpn="dot" // don't offer
DNS over UDP/TCP, only offer DNS over TLS.
*.dot-fallback.example.net DOT 1 "." alpn="dot" // keeps the fallback of
DNS over UDP/TCP, but also offers DNS over TLS.

The problem being addressed is the potential scalability of whatever
technique gets used.
Having the ability to implement things scalably is good.
Mandating anything that does not scale is bad.

Signaling per-zone does not scale well. A dozen or a hundred, maybe okay,
but beyond that, no.

Implementing or enforcing those policies on the name server itself is a
separate issue. It is definitely possible, but not necessarily easy or
free.

I want to emphasize that using the "NS name" gives the NS operator the
ability to offer more choices, without mandating that they do so.
(I.e. Only if the NS operator provides a name-based mechanism, is the zone
admin able to select the desired semantics.)

Basically, if the NS operator offers the scheme, the zone admin would
select the NS name that matches the desired policy features.
One could imagine having an enhanced UI/UX to avoid having the zone admin
know what all this means.

>      N2 fails?  Should it just make a cleartext connection to port 53

It isn't clear what you mean when you say "no signalling is available".
Is this merely "no cached signal is available"?
Or is this the absence of the type of signal that was present at N1, ie not
present at N2.
The rules definitely will need to be codified, but I think it is safe to
say, that everything needs to be backwards compatible.
If no signal is present, assume classic DNS only.
(But, that lack of signal would need to be DNSSEC validated to avoid
downgrade attacks.)

>      hardfail)".  If authentication fails for N2, what should the

Hard fail, and return SERVFAIL to the client. Standard DANE behavior, I
believe.

>      what should the recursor do?

I am confused by the question. In what I'm proposing, all signaling is tied
to N[123], not Z[123].
So, there is no signaling for Z2 per se, only for N2. If N2 authentication
fails, hard fail (same answer).

>  IV. What if the signalling does not indicate hardfail?

Then don't hardfail. However, the signaling needs to authenticate (DNSSEC)
for this to be a legitimate non-hardfail.

>      complete a DoQ connection to N2?

I think the guidance should be, "Do only what is literally signaled", and
if probing/experience shows something that could work but isn't signaled
for use, escalate to a human to communicate with the zone admin or NS
operator to investigate/fix.

Don't encode hacks to fix broken stuff, no matter how tempting it is. So
say we all.

>      (e.g., should it prefer X where it knows some form of encrypted

As much as I'd like for the multiple IP address stuff to work (e.g. it
would make the Root Priming Query a lot simpler), too much legacy stuff
ties things to singleton IP address state.
I don't think there is any benefit to treating them differently, and would
recommend against anyone putting multiple addresses (from a single IP
address family) on a single NS name.

> signal-handling as a deviation from that baseline.

My personal opinion is that this needs to be combined and the unauth case
treated as an optional behavior by the client, rather than anything
explicitly supported by signaling.

Unauth is the antithesis of downgrade resistance. The latter is absolutely
necessary.

> would be neither "per NS name" nor "per zone" but rather it would be

Please, no probing.

The signaling should intentionally differentiate behavior for tuples (zone,
NS IP), by way of NS name.
An authoritative server may (or even should) reject queries for domains
over transport protocols that have not been signaled by whatever mechanism
has been devised for signaling.

If "foo.example" uses "NS ns1.dot-only.example.net", a query for
www.foo.example on port 53 can reasonably expect to get "REFUSED".
However, if "bar.example" uses "NS ns1.dot-or-do53.example.net", a query
for www.bar.example on port 53 should get a real answer.

The whole point of signaling, is to signal authoritatively, and for the
client resolver to depend on that signaling exclusively.

Brian

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 31 Aug 2021 11:51:11 +0200

On Wed, 2021-08-25 at 19:05 -0700, Brian Dickson wrote:
> If "foo.example" uses "NS ns1.dot-only.example.net", a query for www.foo.example on port 53 can reasonably expect to get "REFUSED".

This is not currently reasonable. If you want that to be reasonable, you have a bunch of RFCs to update.

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

---

From: Brian Haberman <[email-masked]>
Date: Tue, 31 Aug 2021 08:11:53 -0400

Any other volunteers?

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 31 Aug 2021 14:23:11 +0200

On 8/17/21 8:16 AM, Brian Haberman wrote:
> I believe we need the following:
> 

I had, at the outset, said that PCH and Quad9 would be immediately implementing any ADoX that makes it as far as running code, and in case that didn’t make it into your notes, I’ll reiterate it now.  As I’ve said before, we STRONGLY PREFER implementations which include TLS client authentication.

                                -Bill

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 31 Aug 2021 17:36:05 +0200

> On Aug 31, 2021, at 2:23 PM, Bill Woodcock <[email-masked]> wrote:
> 

I got a couple of questions about that last sentence, so, more words for the sake of clarity:

From the point of view of an authoritative operator, we would very much like to be able to authenticate the client recursive resolvers using DANE TLS client certs, so as to be able to offer them prioritized service during DDoS attacks, without having to track their multiplicity of changing IP addresses.  i.e. we don’t want to have to track every last source IP address used by the upstream sides of every last Quad9, Cisco, Google, etc. recursive resolver, and we can trust them not to share their TLS client cert with DDoS attackers.

From the point of view of a recursive operator, we would like to be able to authenticate the authoritative server using DANE TLS certs in order to be assure ourselves that we’re not being MITM’d, but we’d also like to be able to authenticate ourselves to the authoritative so that we can receive protected service while the authoritative is under attack.

Right now all this is done with statically-coded IP addresses, which is quickly becoming an insane headache.

                                -Bill