Re: [dns-privacy] scope of authoritative signalling [Was: Re: [Ext] Intermediate proposal (what I was saying at the mic)]

[Brian Dickson <[e-mail]>]

On Tue, Aug 24, 2021 at 11:38 AM Daniel Kahn Gillmor <[e-mail]>
wrote:

> On Thu 2021-08-05 11:06:12 -0700, Brian Dickson wrote:
> >    - 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)
>
> 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
>

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.



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

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.


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

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


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

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


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

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.


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

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.


>
>  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)?
>

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.


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

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.


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

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


>
>                 --dkg
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>