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

[Daniel Kahn Gillmor <[e-mail]>]

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