Subject: [DNSOP] DS glue for NS draft

From: Brian Dickson <[email-masked]>
Date: Wed, 11 Aug 2021 21:15:20 -0400

This is the work I will be submitting in DNSOP.

This is what has been described as a “hack”, but provides a needed validation link for authoritative servers where the latter are in signed zones, but where the served zones may not be signed.

NB: It overlaps with the recent DPRIVE draft that Ben S submitted recently.

It will likely be the case that those overlaps need to be reconciled, based on use cases and scope.

I think there are valuable use cases other than privacy, which would make this more appropriate for DNSOP.

Comments are welcome.

The draft  can be found at:

https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt
Brian

---

From: [email-masked]
Date: Thu, 12 Aug 2021 15:50:15 +0900 (JST)

Hello,

I read draft-dickson-dnsop-ds-hack-00 and it proposes that
  - it assign three new DNSKEY algorithms (alg_ns, alg_A, alg_AAAA)
  - it generate 3 new DS RRs for all parent side NS RR and glue (A/AAAA)

It will increase DS reponse 48bytes * 3 = 144 bytes. (in case of digest type 2)

  owner IN DS 0 alg_NS digest hash_of(caonnical_order(NS RRset))
  owner IN DS 0 alg_A digest hash_of(caonnical_order(glue A))
  owner IN DS 0 alg_AAAA digest hash_of(caonnical_order(glue AAAA))

Please add such examples.

The caonical ordering is defined in RFC 4034 and your draft depends on
draft-ietf-dnsop-glue-is-not-optional. Please add them as references.

I proposed similar idea "Delegation Information (Referrals) Signer for
DNSSEC" at IETF 109 dnsop WG and it was not preferred at the time.

See:
https://datatracker.ietf.org/doc/html/draft-fujiwara-dnsop-delegation-information-signer-00

My idea generates one DS resource record for each delegation point.
Signer and verifier generates complete NS RRset and glue set,
reorder canonical order, and calculate hash.

owner IN DS ? new_alg? new_digest? hash_of(caonnical_order(NS RRset)|canonical_order(glue RRset))

--
Kazunori Fujiwara, JPRS <[email-masked]>

> From: Brian Dickson <[email-masked]>
> This is what has been described as a “hack”, but provides a needed validation
> link for authoritative servers where the latter are in signed zones, but where
> the served zones may not be signed.
>

---

From: "John Levine" <[email-masked]>
Date: 12 Aug 2021 12:21:49 -0400

It appears that Brian Dickson  <[email-masked]> said:
>-=-=-=-=-=-
>This is what has been described as a “hack”, but provides a needed validation link for authoritative servers where the latter are in
>signed zones, but where the served zones may not be signed.
>

It looks to me like the main difference between the drafts is that Ben's scheme uses one new 
faux algorithm and puts the rrtype inside the encapsulated data, while yours uses one per rrtype.
The goals look a little different but other than where the rrtype is encoded the mechanisms
look the same.

In both drafts I would like to see clearer explanations of what you do when the signed glue
disagrees with their authoritative non-glue versions.  I'm having some trouble figuring out
exactly what "authoritative" means here.

R's,
John

---

From: Brian Dickson <[email-masked]>
Date: Thu, 12 Aug 2021 15:26:18 -0400

Sent from my iPhone

> On Aug 12, 2021, at 12:21 PM, John Levine <[email-masked]> wrote:
> 

Not quite. IIIRC, in both cases, the record(s) contain only the hashes of datum/data, which is a one-way function.

Unpacking isn’t possible when recreating the hash.

Having one DS per type (and possibly per record) is a small bump in total size, but is more resilient to semantic errors (including things that might not be added as glue by the parent) and any sort of rollovers (change of glue records, change of servers).

> The goals look a little different but other than where the rrtype is encoded the mechanisms

It isn’t. The one way hash means the validate is unable to determine what rrtypes are present.

In the one rrtype per DS, that encoding is possible to determine (trivially).

> disagrees with their authoritative non-glue versions.  

You replace the non-auth glue with auth data, same as today. (But only if it is in an answer section, and ideally in a situation where that zone is signed).

If the signature on the DS set doesn’t validate , retry. Validation of the NS set and glue data would be done by recreating the hash(es) and looking for a match in the set of DS records whose signature  was validated. Only validated records should be used. NSEC(3) proves whether any DS exists. The child is not required to be signed, eg if no “standard” DS records exist.

> I'm having some trouble figuring out

The DNS server serving the child zone.
If the child is “registrant1.example”, and the NS set includes “ns1.dns-op2.example”, the authoritative server is the latter.
If THAT zone are itself has NS set including only names like “ns[0-9].dns-op2-names.example”, then the zone dns-op2.example would be glueless (no A/AAAA glue is provided except for sibling glue). The dns-op2-names would ideally have in-bailiwick NS and non-optional glue.
The last set would be the only ones with the second and/or third algorithm.

All three zones are delegated, and depending on the respective values might be on two different sets of servers. Both of those server sets would be authoritative servers.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 13 Aug 2021 11:40:07 -0400

On Thu, Aug 12, 2021 at 12:22 PM John Levine <[email-masked]> wrote:

> >This is what has been described as a “hack”, but provides a needed
> validation link for authoritative servers where the latter are in

I think we can summarize the recent DS-glue-signing drafts as follows:

* draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a
hash of all the glue records.
* draft-dickson-dnsop-ds-hack: Each new DS holds the hash of one glue RRSet
* draft-schwartz-ds-glue: Each new DS holds one glue record verbatim

These represent three of the six possible combinations of scope (RR, RRSet,
all glue) and encoding (hash vs. verbatim).  All six combinations are
possible, with different tradeoffs.

The goals look a little different but other than where the rrtype is
> encoded the mechanisms

These approaches are certainly related, but they have some crucial
differences in terms of
* degree of coherence required between DS and glue
* ability to support new glue RR types
* support for authenticated nonexistence
* amount of response bloat

Notably, the hash-based methods either (a) require glue and DS to be
updated atomically (incompatible with CDS) or (b) require a multi-phase
commit to update the DS and glue, relying on some kind of lax validation
behavior during the transition.  Getting the lax validation right for the
RR and RRSet scopes is Not Easy.

In both drafts I would like to see clearer explanations of what you do when
> the signed glue

FWIW,
https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01#section-3.2
says

   Source Records reconstructed from DSGLUE SHOULD be processed exactly
   like ordinary unauthenticated glue records.  For example, they MAY be
   cached for use in future delegations but MUST NOT be returned in any
   responses (c.f.  Section 5.4.1 of [RFC2181]).

---

From: "John R Levine" <[email-masked]>
Date: 13 Aug 2021 12:39:29 -0400

> * draft-schwartz-ds-glue: Each new DS holds one glue record verbatim

Thanks, this is very useful.

> FWIW, 
> https://datatracker.ietf.org/doc/html/draft-schwartz-ds-glue-01#section-3.2 says
>

I get that, but it still seems odd to have signed-but-not-authoritative in 
between unsigned and signed. If you're not supposed to treat them as any 
more credible than unsigned glue, what's the point of signing them?

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

---

From: Ben Schwartz <[email-masked]>
Date: Fri, 13 Aug 2021 13:18:03 -0400

> more credible than unsigned glue, what's the point of signing them?

As with ordinary DNSSEC, the point of signing the records is to enable
resolvers to detect tampering.  The immediate motivation (from DPRIVE ADoT)
is to stop iterative resolution before sending the query to an attacker's
nameserver.

At its core, all DNSSEC does is SERVFAIL/Bogus if an attack is detected.
Valid records are treated almost exactly like records in an unsigned zone.
Similarly, valid DSGLUE is treated almost exactly like unsigned glue.

This isn't the only possible design, but I think it's the right one.
Mixing the AA bit and the AD bit seems like it could create confusion, and
having glue records overriding values in the child zone seems like an
operational headache.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Aug 2021 19:47:12 +0000

On Aug 13, 2021, at 8:40 AM, Ben Schwartz <bemasc=[email-masked]> wrote:
> * draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a hash of all the glue records.
> These represent three of the six possible combinations of scope (RR, RRSet, all glue) and encoding (hash vs. verbatim).  All six combinations are possible, with different tradeoffs.

This concise list also points out a very serious terminology problem that affects this discussion: unsigned NS records in a response are not glue records. Similarly, SVCB records are not glue records.

Proposed differentiation between the drafts:

* draft-fujiwara-dnsop-delegation-information-signer: One new DS holding a hash of the NS records in the Authority section and all the address records in the Additional section

* draft-dickson-dnsop-ds-hack: Each new DS holds the hash of NS records in the Authority section, the A records in the Additional section, and the AAAA records in the Additional section

* draft-schwartz-ds-glue: Each new DS holds one record verbatim; the record might not appear in the rest of the response

For the DRPIVE use cases, draft-schwartz-ds-glue allows a resolver to discover SVCB records in a response from the parent, even if that parent is not configured to put SVCB records in the Additional section.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Sat, 14 Aug 2021 19:36:58 -0400

On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman <[email-masked]> wrote:

> > These represent three of the six possible combinations of scope (RR,
> RRSet, all glue) and encoding (hash vs. verbatim).  All six combinations
> are possible, with different tradeoffs.
>
> This concise list also points out a very serious terminology problem that
> affects this discussion: unsigned NS records in a response are not glue
> records. Similarly, SVCB records are not glue records.
>

I agree that more conciseness and precision are important to this
discussion.

Here are some further clarifications from the above list, in no particular
order:

   - draft-fujiwara-dnsop-delegation-information-signer specifies that the
   parent is responsible for creating/maintaining the DS records
   - draft-dickson-dnsop-ds-hack specifies (or implies, or will be updated
   to specify) that the child creates the DS hashes and via one method or
   another transmits them to the parent (e.g. CDS, CDS polling by Registrar
   and EPP, etc)
   - All of the three require new DNSKEY algorithms, and
   draft-schwartz-ds-glue requires a new "hash" (technically "verbatim" is a
   type of hash)
   - All of these would return the DS record(s) in the authority section
   alongside the NS record, even if the glue data (A/AAAA) were returned in
   the additional section.

> hash of the NS records in the Authority section and all the address records
> in the Additional section
>
> * draft-dickson-dnsop-ds-hack: Each new DS holds the hash of NS records in
> the Authority section, the A records in the Additional section, and the
> AAAA records in the Additional section
>
> * draft-schwartz-ds-glue: Each new DS holds one record verbatim; the
> record might not appear in the rest of the response
>
> For the DRPIVE use cases, draft-schwartz-ds-glue allows a resolver to
> discover SVCB records in a response from the parent, even if that parent is
> not configured to put SVCB records in the Additional section.
>

While this is technically accurate, it is (IMNSHO) problematically insecure.
SVCB records in a signed child domain would be protected by a real DS
record (signed by parental RRSIG), and RRSIG in the child domain.
Any SVCB record added to the parent domain via the "ds-glue" mechanism
would NOT be signed by the child. The RRSIG of the new DS record would
prove that the new DS record was not tampered by an active attacker (etc),
but would not provide the data integrity offered by DNSSEC.

I'm a strong advocate of discovery and use of SVCB records for both
opportunistic and downgrade-resistant (authenticated) use cases.

SVCB in the child nameserver name domain is the right place to put SVCB
records, as the name server name is the association needed for TLS.
The resolver talking TLS will be talking to the name server, to make
encrypted queries about a domain served by the name server.
(The domain served that is being queried is presumed to not have an
in-bailiwick name server, since that particular corner case is a
chicken/egg problem.)

The alternative (to requiring the SVCB record in the child, signed by the
child domain) might be an SVCB-like thing in the parent which contains data
signed by the child. Specifically:

   - A DNSKEY algorithm, or component of the draft-schwartz encoding, which
   contains (SVCB + RRSIG_name_server_child_ksk(SVCB))
   - This would be signed by the parent too, but the critical component the
   provides the data integrity from the child is the
   RRSIG_name_server_child_ksk element
   - Only the operator of the name server's name's domain (which possesses
   the name_server_child_ksk) can generate this signature
   - This is much stronger than being able to push data over an EPP
   channel, which is the mechanism available to a Registrar that polls the
   Registrant's domain for CDS records
   - EPP does not have a mechanism currently for validation of supplied DS
   records
   - Updates to EPP are not in scope for DNSOP itself

Some other clarifications/explanations about draft-dickson-dnsop-ds-hack:

   - The current draft specifies that the current preferred existing hash
   algorithm (alg 2, sha2-256) is to be used, precisely and solely because
   that does not require new hash algorithms to be specified by dnsop via
   standards action (or whatever is done to change how new algorithms get
   adopted) and implemented by Registries and Registrars. In other words, the
   expectation is that use of hash alg 2 reduces or removes barriers to
   deployment
   - The one DNSKEY algorithm for each of NS, A, and AAAA encodings is
   designed to minimize the challenges of matching NS, A, and AAAA records to
   these DS hashes
   - The current -00 version has all the NS records lumped together in one
   RDATA hash. That might change in later revisions to have one DS per NS
   record to further simplify the matching, and to better handle update
   processing (specifically the async nature of updates and long-TTL records
   that may be cached).
   - The DS hash algorithms and DNSKEY algorithms are orthogonal. The
   choice of DNSKEY algorithm does not require that DS hash algorithm 2 be
   used per se; any future DS hash algorithm (including a NULL hash, i.e.
   verbatim) would be just as useable/deployable, at such time as it is widely
   deployed by registries and registrars

There may be some ability to converge on some elements of these drafts.
However, deployability is my main concern, and was a significant driver in
the design choices.

Brian

---

From: Paul Wouters <[email-masked]>
Date: Sun, 15 Aug 2021 12:09:35 -0400 (EDT)

On Sat, 14 Aug 2021, Paul Hoffman wrote:

> This concise list also points out a very serious terminology problem that affects this discussion: unsigned NS records in a response are not glue records.

I disagree. While I understand that RFC 8499 explains glue as:

  Glue records:  "...[Resource records] which are not part of the
       authoritative data [of the zone], and are address RRs for the
       [name] servers [in subzones].

And so yes, since conveying secure transport _to_ a nameserver is not an
address RR, technically this would fall outside the definition of glue.

but clearly the spirit of the meaning of glue is that these are "any
child zone records at the parent needed to properly contact the child
nameserver", and in that sense, conveying a public key for secure
transport to the child nameserver is clearly "glue".

Paul W

---

From: Paul Vixie <[email-masked]>
Date: Sun, 15 Aug 2021 16:53:33 +0000

On Sun, Aug 15, 2021 at 12:09:35PM -0400, Paul Wouters wrote:
> > This concise list also points out a very serious terminology problem ...
> 
> ... clearly the spirit of the meaning of glue is that these are "any

+1.

-- 
Paul Vixie

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Aug 2021 11:16:05 -0400

> On Sat, Aug 14, 2021 at 3:47 PM Paul Hoffman <[email-masked]>
...

> but would not provide the data integrity offered by DNSSEC.

I don't agree with this characterization.  In the DNSSEC security model,
data signed by the parent has the same level of DNSSEC protection as data
signed by the child.

> records, as the name server name is the association needed for TLS.

To avoid misunderstanding: SVCB itself does not alter the nameserver name
used for TLS.  The nameserver name is the name in the NS record, regardless
of what SVCB says.  ("TLS clients MUST continue to validate TLS
certificates for the original service name",
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-2.3
)

>    - A DNSKEY algorithm, or component of the draft-schwartz encoding,
>    which contains (SVCB + RRSIG_name_server_child_ksk(SVCB))
>    - This would be signed by the parent too, but the critical component
>    the provides the data integrity from the child is the
>    - Only the operator of the name server's name's domain (which
>    possesses the name_server_child_ksk) can generate this signature
>
> Yes, but the parent controls the choice of nameserver name, so this does
not create an effective defense against a hostile parent, which is
impossible under standard DNSSEC assumptions.

>    - EPP does not have a mechanism currently for validation of supplied
>    DS records
>
> I don't understand.  When using CDS, the CDS records are validated by
DNSSEC from the current DS.  Otherwise, the DS records are authenticated by
the registrar's usual login procedure.  Either way, any adversary who could
forge DS records could also forge RRSIGs or any other RR type.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Aug 2021 14:04:48 -0400

On Mon, Aug 16, 2021 at 11:16 AM Ben Schwartz <[email-masked]> wrote:

>
>
> On Sat, Aug 14, 2021 at 7:37 PM Brian Dickson <
> [email-masked]> wrote:
>
>>
>>
I'm arguing against the parent ever putting SVCB records in any delegation
response, regardless of whether the data is signed, or whether the parent
is capable of doing so. The data model for doing so is IMNSHO incorrect.

The parent is responsible for signaling the delegation, and everything else
is necessary for resolution, but not authoritative.
The "glue is necessary" draft clarifies this.
Protecting that glue improves the security model of that glue, which is
essentially "where do I go to get the child zone"?
DNSSEC provides the necessary protection on the data integrity on the
zone(s), but not the name server(s).

The security model for name server names' zones mirrors that of
registrant's zones, since it uses the exact same standards (DNSSEC).

There is no DNSSEC model for avoiding a two-phase method for obtaining any
signed data from the name server names' zone(s).

The best that can be done without re-engineering DNSSEC, is the benefits of
caching the first phase (getting the validated DNSKEY(s) for the name
server names' zone(s), which are used to validate RRSIGs on data served in
those zone(s), needed for getting TLSA records if those are used.)

The larger discussion of strictly opportunistic vs downgrade-resistant TLS
to the authority server, needs to happen first, IMHO.

Those two models are fundamentally incompatible. You cannot have strictly
opportunistic (using WebPKI) and also have downgrade-resistant TLS.

The prior work by Viktor in the DANE SMTP has pretty much cemented that, as
well as having demonstrated that this is both feasible and scalable.

> data signed by the parent has the same level of DNSSEC protection as data

In the DNSSEC security model, the only parental data that is signed is the
DS record (and obviously NSEC(3) records).
The security model on the DS record is that all of the following are part
of the secure delegation that get validated (by validating resolver):

   - RRSIG on DS record is verified using ZSK (or CSK) of the parent domain
   - Child domain apex is queried for matching KeyTag KSK with matching
   DNSKEY algorithm
   - Child domain RRSIG(s) over DNSKEY set verified (but the latter are not
   yet part of the trust set)
   - DS record is recreated from inputs, and compared to DS received
   originally

You cannot take child data and place it in the parent, and sign it with the
parent's ZSK, and claim it has the same degree of protection as when it was
signed by the child ZSKs.

> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-07#section-2.3

At issue is not whether the name is changed, it is who is authoritative for
the data at the owner name, which is the child zone.
The SVCB also is controlling the transport and potentially other parameters.
Absent a discussion on how to securely get that data into the parent, it
cannot be accurately asserted as having the same security properties as
when the SVCB record is published in a signed child zone.

> impossible under standard DNSSEC assumptions.

None of this has anything to do with a potential hostile parent, not sure
why you are raising that.

But I think it is probably a moot point to discuss any other method of
encoding SVCB in the parent.

There are a lot of other reasons why SVCB in the parent has characteristics
that are not suitable.

   - TTL on the parent side is controlled by the parent, not the child
      - This has operational impacts, particularly if problems occur and a
      roll-back is necessary
   - TTL on the child side is controlled by the child (which is likely to
   be important when rolling out new features, or making changes)
      - TTL can be adjusted up/down as needed for planned maintenance work
   - Frequency of updates for current DS records, is basically "when KSK
   rolls", which is on the order of year(s)
      - Encoding glue via DS, involves updates whose frequency aligns with
      changes to that glue, also typically stable for years at a time
   - Changes to SVCB would require regenerating RRSIGs.
      - Doing that imposes impact to the signing zone (signature frequency
      is typically bound by hardware, and upping the former requires
more of the
      latter)
      - That also presupposes that the proposed frequency can even be
      supported
      - If the signing is done by the child, the cost is borne by the party
      making the changes
      - If the signing is done by the parent, the cost is not borne by the
      party making the changes
   - The SVCB RDATA is not actually authoritative on the parent side (bears
   repeating, this has a lot of implications, including infosec issues)

Also, it is not clear from the discussion thus far, on which record(s)
would have that SVCB record included:

   - The registrant's zone name (delegation from the parent to the DNS
   Operator's server)
   - The DNS Operator's zone name (possibly glue-less XOR possibly having
   in-bailiwick glue required)
   - The Zone serving the name server names (referenced in the NS records
   of the registrant's zone)

The first one would not be reasonable at all, since presumably the
registrant would have the ability to submit SVCB records even if the
registrant did not operate the authoritative DNS server.

> forge DS records could also forge RRSIGs or any other RR type.

This is a "chain of custody/control" thing. If the Registry is not doing
CDS directly, the CDS model has failed to protect the DS update end-to-end.
While another party (Registrar) polling and validating CDS would be
_necessary_, it would not be _sufficient_.

There are only a handful of CCTLDs doing CDS, and I am not aware of any
significant plans beyond those currently.
CDS _by the Registry_ is incompatible with the RRR model, i.e. the gTLD
mechanism controlled by ICANN contracts.
That is highly unlikely to change in a timeframe faster than multiple
years, if ever.

Basically, I don't foresee CDS done by Registries being relevant to any
proposals for securing the glue data.

Securing existing glue (no new data per se, but adding encoding and
signing) is something Registries could do, and pursuing that has potential.

Adding new data on the parent side is likely to be problematic.

Thus, the concept of using DS records to encode _existing_ data to enable
validation, is likely to not be controversial.
It is the difference between "letter of the law" and "intent of the law".
IMHO, at least.

So, TL;DR: CDS isn't going to happen outside of a handful of ccTLDs. DS
encoding would work fine for existing glue. Who does that and how it gets
added to the parent is a (the?) problem that needs to be solved. SVCB (or
similar) in the DNS operators' zones is adequate for downgrade-resistant
TLS.

Also, optimizing for cold cache vs warm cache should be explicitly called
out. It looks to me like "SVCB in parent" is only valuable in the cold
cache scenario. Stats are probably available showing how often queries are
made for DNS operator's zones that indicate a cold cache is being used.
Absent a compelling case for the cold cache, it does not seem to be worth
any effort.

Brian

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Aug 2021 15:14:03 -0400

On Mon, Aug 16, 2021 at 2:05 PM Brian Dickson <[email-masked]>
wrote:
...

> The parent is responsible for signaling the delegation, and everything
> else is necessary for resolution, but not authoritative.
>

I think we can and should view the server configuration hint (e.g. SVCB) as
"necessary for resolution".  Otherwise, we would be asking resolvers to add
a round-trip delay (a "synchronous binding check") to every single DNS
delegation, in order to check whether a SVCB record exists before
proceeding.  I believe this is untenable: our first deployment step can't
be to slow down the whole internet.  The resolver operators I've spoken to
have made it clear that they will not implement any behavior with that kind
of impact.

Even if we can somehow limit this "synchronous binding check" to domains
that have opted-in, we would still be adding a round-trip delay to all
delegations in the long term, when encryption is widely deployed.  I don't
see any operational concern here that could outweigh the cost of making the
whole internet slower.

...

> At issue is not whether the name is changed, it is who is authoritative
> for the data at the owner name, which is the child zone.
>

I agree.  That's why I think it's wisest to require that any records
provided by the parent are only used for delegation, and never returned to
the stub.

> The SVCB also is controlling the transport and potentially other

These parameters are thoroughly analogous to the IP addresses in glue A
records today.  In both cases, we are discussing information that is used
to connect to the nameserver, not information that will be returned to the
stub as zone contents.

>>> The alternative (to requiring the SVCB record in the child, signed by
>>> the child domain) might be an SVCB-like thing in the parent which contains
>>> data signed by the child. Specifically:
>>>

Security is defined by a threat model.  if the parent is excluded from the
threat model, as we seem to agree, then anything signed by the parent is
fully secure by definition.

> There are a lot of other reasons why SVCB in the parent has
> characteristics that are not suitable.
>
>       - This has operational impacts, particularly if problems occur and
>       a roll-back is necessary
>
>  I don't see a difference here from the status quo with NS, A, and AAAA
glue records.

>       - Encoding glue via DS, involves updates whose frequency aligns
>       with changes to that glue, also typically stable for years at a time
>
> There is no reason to expect frequent changes to any of the relevant
records.  Even TLSA records would not be rotated more than a few times a
year.

>       - Doing that imposes impact to the signing zone (signature
>       frequency is typically bound by hardware, and upping the former requires
>       more of the latter)
>       - If the signing is done by the child, the cost is borne by the
>       party making the changes
>       - If the signing is done by the parent, the cost is not borne by
>       the party making the changes
>    - The SVCB RDATA is not actually authoritative on the parent side
>    (bears repeating, this has a lot of implications, including infosec issues)
>
> Yes, but there is no need for it to be authoritative, because it would
never be returned as zone contents.  We already use non-authoritative data
to establish a connection to a nameserver, so that's nothing new.

> registrant did not operate the authoritative DNS server.

SVCB records would only be accepted on in-bailiwick delegations, i.e. the
same delegations that include A/AAAA glue today.  I believe this is your
third case, although there can technically be multiple in-bailiwick
delegation steps in the course of a single iterative resolution.

> _necessary_, it would not be _sufficient_.

It sounds like you are saying that a compromised or hostile Registrar
should be part of our threat model.  I do not think this is necessary or
practical.  A compromised Registrar can always replace the entire child
zone contents, so nothing we place in the child zone can defend against it.

> proposals for securing the glue data.

Perhaps, but some Registrars have already implemented support, e.g.
https://glauca.digital/blog/2020/08/10/cds-at-the-registrar-level.html.
Domain owners that wish to publish via CDS can already choose such a
Registrar, and use CDS for automated maintenance with any Registry.

...

> cache scenario.

I agree!

> Stats are probably available showing how often queries are made for DNS
> operator's zones that indicate a cold cache is being used. Absent a
> compelling case for the cold cache, it does not seem to be worth any effort.
>

Perhaps we can find some stats, but I think the "cold cache" case is worth
optimizing for reasons of tail latency and consolidation pressure.  Cold
cache delegations already resolve slower, so making them even slower is
likely to have a disproportionate impact on tail latency.  Low-traffic
nameservers are much more likely to be cold in cache, so increasing the
latency penalty for a cache miss would increase pressure to migrate to
centralized nameservers.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 16 Aug 2021 19:40:41 -0400

On Mon, Aug 16, 2021 at 3:14 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Mon, Aug 16, 2021 at 2:05 PM Brian Dickson <
>> I'm arguing against the parent ever putting SVCB records in any
>> delegation response, regardless of whether the data is signed, or whether
>> the parent is capable of doing so. The data model for doing so is IMNSHO
>> incorrect.
>>
> I think we can and should view the server configuration hint (e.g. SVCB)
> as "necessary for resolution".  Otherwise, we would be asking resolvers to
> add a round-trip delay (a "synchronous binding check") to every single DNS

I think it is time to actually work through an example, as your assertion
("every single DNS delegation") does not align with my understanding.

Suppose we have the following domain delegation at the "example" TLD:
foo.example NS ns1.out-of-bailiwick.example

And suppose there is an SVCB record for the name server, served by the
authoritative server for the "out-of-bailiwick.example" domain:
_853._tcp.ns1.out-of-bailiwick.example SVCB (parameters)

In a cold cache, this SVCB query would need to be made (obviously).

However, now consider a subsequent stub client query to the same resolver,
for "bar.example", with delegation as follows:
bar.example NS ns1.out-of-bailiwick.example

If the cached SVCB record is still present in the resolver's cache, i.e.
the cache is warm, the SVCB record would be locally found in the cache (and
there would not be any additional RTTs.)

Am I misunderstanding the SVCB usage, or is the example set not correct in
some way?

In addition to the above, the "out-of-bailiwick.example" zone could also
contain things like:
ns1.out-of-bailiwick.example A (some address)
ns1.out-of-bailiwick.example AAAA (some address)
ns1.out-of-bailiwick.example TLSA (tlsa record parameters)

Depending on the resolver's policies and authoritative
server's functionality etc., the number of RTTs required and original
QNAME/QTYPE might vary.
But, once those are all cached, all subsequent queries for domains served
by ns1.out-of-bailick.example would not require additional RTTs.
(Add DNSKEY queries as necessary, and RRSIG validation processing as
first-iteration overhead).

>>>>    - This would be signed by the parent too, but the critical
>>>>    component the provides the data integrity from the child is the
>>>> Yes, but the parent controls the choice of nameserver name, so this
>>> does not create an effective defense against a hostile parent, which is

The parent can be trustworthy, but not the communications to the parent
(EPP). Those are not equivalent elements of the threat model.
This is especially true concerning the signing processes.
The signing itself can be super-safe with all kinds of practise statements,
but that does not mean there is not a weakness on the data upload path.
The latter is input to the signed data, and is the weak point in the
overall system.

>>  I don't see a difference here from the status quo with NS, A, and AAAA

The NS records reference names (RDATA values), but the names may be
"glue-less", e.g.

   - The delegated domain and NS are not under the same TLD
   - The NS domain is itself glueless (served by name servers not under the
   same domain as the NS names)
      - Example:
         - foo.example NS ns1.out-of-bailiwick.example
         - out-of-bailiwick.example NS ns1.dns-operator-domain.example
         - ns1.dns-operator-domain.example A glue-A-record
      - This is a counter-example, showing that there may not even be A and
      AAAA glue records involved that correspond to SVCB records
      - The SVCB record, if present, would be tied to
      "ns1.out-of-bailiwick.example"

>
>>    - TTL on the child side is controlled by the child (which is likely
>>    to be important when rolling out new features, or making changes)

I think you are projecting from individual practices onto the entire
industry's operational practices.
Just because *some* TLSA records might not change often, does not mean
*all* TLSA records will not change often.
I can probably point to counter-examples.

Also, the frequency of changes is not the same as the impact of TTL on
changes (cached records in some resolvers' caches, vs newly queried records
in other resolvers' caches.

There are other issues that you haven't discussed here yet:

   - There may be different anycast locations, topologies, and policies,
   vis a vis TLSA records
      - Different DNS Operator anycast instances may serve different TLSA
      records (geographically aligned values)
      - TLD delegation glue does not generally support such differentiated
      views
      - Even if some TLDs did support these views, the locations may not
      align properly
      - Some locations may not even offer TLS service, for name servers
      with the same name
   - (Other things I can't think of right now...)

> to establish a connection to a nameserver, so that's nothing new.

Except this is new, and is precisely the case where using non-authoritative
data to establish a connection to the name server would break the
assumptions needed for privacy.

>>    - The DNS Operator's zone name (possibly glue-less XOR possibly
>>    having in-bailiwick glue required)
>>    - The Zone serving the name server names (referenced in the NS
>>    records of the registrant's zone)
>>

See above. The second bullet being glueless and the third being glue-full,
would mean the SVCB record would not have associated glue and thus no v4 or
v6 hints.

>>>>    - EPP does not have a mechanism currently for validation of
>>>>    supplied DS records
>>>>

It has nothing to do with whether the Registrar is hostile or not. If the
data is not authenticated by the TLD, the chain of custody has been broken.
This is a problem with lack of alignment in the security model between
Registrar polling (using CDS records, signed by the Registrant or the
Registrant's DNS Operator) and EPP submission (which uses Registrar
credentials, not Registrant credentials).

An example of a trustworthy Registry and trustworth Registrar communicating
over TLS, still being potentially compromised:
If the Registry's TLS connection was MITM'd by an on-path adversary with a
valid TLS cert issued by a different CA, which was in the trusted CA set
for the Registrar, the DS update could be tampered with.
If the DS record was signed, and the Registry validated the signed DS
record, this tampering would not be possible, and there would not be any
reliance on CAs or TLS certs. Data integrity is different from channel
integrity.

The threat model is not relevant if there is a lower-trust component in the
update. CDS is cryptographically strong (CDS signed by existing DNSKEY
private key), while Registrar credentials are not (at least generally,
today).

It is a significant problem that I think needs to be addressed.

The interim mechanisms for protecting against these weaknesses do not scale
well - i.e. Registry Lock, which is incompatible with frequent DS changes.

> Registrar, and use CDS for automated maintenance with any Registry.

Even if every Registrar supported this, it does not change the RRR security
model that underlies everything, outside of the CCTLDs doing CDS.
They all rely on EPP, with no data integrity check on submitted DS records
associated with such CDS updates.
The Registry can be completely trustworthy, but the weak link is unchanged
-- the Registrar-Registry update mechanism, which relies on Registrar
credentials.
Those credentials are applicable to use for updates to any/all Registrant
records (i.e. every Registrant that uses that Registrar).
It doesn't mean the Registrar isn't trustworthy either.
It only means the model is not as secure as would be the case if the data
required "proof of possession" of the private key, e.g. signing the DS.

---

From: Joe Abley <[email-masked]>
Date: Mon, 16 Aug 2021 20:07:31 -0400

On Aug 16, 2021, at 19:41, Brian Dickson <[email-masked]> wrote:

>> [...]

This thread makes me think draft-jabley-dnsop-refer wasn't as insane and operationally complex as I thought.

Joe

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Aug 2021 21:02:21 -0400

> This thread makes me think draft-jabley-dnsop-refer wasn't as insane and operationally complex as I thought.

The impact of such an attack would be to
   eliminate any benefits of the REFER Mechanism and revert to the
   security characteristics of the Standard Mechanism.

As long as you proposal is vulnerable to downgrade attacks, it does not actually change anything.

It only adds a little audit trail if the parent turns out to be malicious but that too can be mitigated by the parent by replacing the entire child.

Paul

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 16 Aug 2021 21:15:01 -0400

...

I think we agree: we are talking about an extra RTT for every in-bailiwick
delegation that is not in cache.  (And every iterative resolution sequence
includes at least one in-bailiwick delegation step.)

...

>> Security is defined by a threat model.  if the parent is excluded from
>> the threat model, as we seem to agree, then anything signed by the parent
>> is fully secure by definition.
>>
>
> The signing itself can be super-safe with all kinds of practise
> statements, but that does not mean there is not a weakness on the data
> upload path.

EPP controls the DS contents regardless, and hence the security anchor of
the entire registered domain.  If you have a security problem with EPP,
you'll have to address it before we get to the point of resolvers reading
the DS records.  At that point, an attacker who controls EPP has already
won the game.

>>>       - This has operational impacts, particularly if problems occur
>>>       and a roll-back is necessary
>>>
>    - The NS domain is itself glueless (served by name servers not under
>    the same domain as the NS names)
>       - Example:
>       - This is a counter-example, showing that there may not even be A
>       and AAAA glue records involved that correspond to SVCB records
> I don't understand.  In all of those cases, the TTLs of the NS, A, and
AAAA records used during delegation are controlled by the various parent
domains.  Why is that OK for NS, A, and AAAA but not OK for SVCB?

>>>    - Frequency of updates for current DS records, is basically "when
>>>    KSK rolls", which is on the order of year(s)

Here's some text from draft-schwartz-ds-glue-01, Section 6.3:

   As an optimization, nameservers using DANE MAY place a TLSA record in
   the DSGLUE to avoid the latency of a TLSA lookup during delegation.
   However, child zones should be aware that this adds complexity and
   delay to the process of TLSA key rotation.

So if you want to rotate your TLSA key so frequently that you hit rate
limits on your DS updates, you should just omit it from the glue and pay
the 1-RTT penalty.

> The DNS offers no guarantees about preserving cache geolocality, so this
is a recipe for breakage regardless.  Route flaps, for example, could cause
a record from one location to be used in another.
...

> Except this is new,

Yes!  That means that there is no rule here.  It is up to us.

> and is precisely the case where using non-authoritative data to establish
> a connection to the name server would break the assumptions needed for
> privacy.
>

No, I don't follow this at all.  The assumption for privacy is that a
network intermediary, i.e. an adversary with no access to relevant private
key material, cannot capture the query contents.  A signature by the parent
is entirely sufficient for this.

> would mean the SVCB record would not have associated glue and thus no v4 or

No, I don't follow.  SVCB records would appear in exactly the same places
as A/AAAA glue, i.e. in-bailiwick delegations only.

...

> data is not authenticated by the TLD, the chain of custody has been broken.

If Registrar instructions are accepted by the Registry without
authentication, then DNSSEC is broken because a network adversary can
control the zone keys.  If bugs of that kind are present in the wild that
is a very serious matter, but it's entirely separate from this discussion,
which starts from the assumption that DNSSEC is implemented securely.  (The
same would be true of any DNSSEC implementation bug.)

> An example of a trustworthy Registry and trustworth Registrar
> communicating over TLS, still being potentially compromised:

That is an attack to consider, but it doesn't qualify as "not
authenticated".  Rather, it represents a trusted party (a CA) becoming
untrustworthy, compromising the security of the system.

Strengthening the DNS against untrustworthy CAs could be an interesting
project, but it is out of scope here.

> reliance on CAs or TLS certs.
>

Ultimately, some authority is needed for the Registry to know whether
they are talking to an accredited Registrar.  If this authority is
delegated to a poorly chosen party, that is unfortunate, but we can't fix
it here.

> Data integrity is different from channel integrity.
>
> The threat model is not relevant if there is a lower-trust component in
> the update. CDS is cryptographically strong (CDS signed by existing DNSKEY

That sounds like a TOFU model, on the assumption that the initial DNSKEY
was not tampered with.  However, the Registrar always needs the ability to
override the child's claim to ownership, in order to rescind the
registration (e.g. due to non-payment), so this cannot even offer full TOFU
security.

I would welcome a draft addressing it, but I don't think it has anything to
do with this discussion about authenticating delegation information.

> The interim mechanisms for protecting against these weaknesses do not
> scale well - i.e. Registry Lock, which is incompatible with frequent DS
> changes.
>
>
>>
> Even if every Registrar supported this, it does not change the RRR
> security model that underlies everything, outside of the CCTLDs doing CDS.

This does not seem like a fair description.  The Registrar is identified by
a certificate issued by some mutually trusted authority, which signs a
transport (TLS) that includes data integrity protection.

> required "proof of possession" of the private key, e.g. signing the DS.

Sounds good to me.  You could write a draft for REGEXT.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 18 Aug 2021 15:07:06 -0400

Apologies to anyone following this thread... these messages are getting
very large, necessarily.
(Paul H, you may want to skip down to an example I provided, look for
ORIGIN text.)

On Mon, Aug 16, 2021 at 9:15 PM Ben Schwartz <[email-masked]> wrote:

>
>
> On Mon, Aug 16, 2021 at 7:40 PM Brian Dickson <

You haven't responded to the worked example, only reiterated a tautological
statement (true by definition only) with very limited relevance.

If a domain is delegated to a name server that is in-bailiwick, clearly
that would require one RTT to obtain any information in that domain.

However, it is also the case that in the context of privacy, talking to
that name server directly reveals to any on-path observer that the resolver
is interested in records in that self-same domain. This is the use case
where it is literally impossible to bootstrap to a private connection
without doing one of two things: probing for a secure connection (e.g.
attempting a connection on port 853) AND having that connection being
subject to downgrade by an on-path attacker, or having the necessary
parameters provided by the delegating (TLD) name server, which is something
ONLY required in the case of the in-bailiwick name server for the
domain-of-interest.

In all other cases, the domain is delegated to a name server whose name is,
by definition, not in-bailiwick for the domain-of-interest.

Yes, the name server name itself may (or may not) be in-bailiwick, but the
privacy concerns on that initial connection are limited to inferred, rather
than directly observed, information.

So, the only impact on RTTs exists if the first domain-of-interest is
queried on a given non-bailiwick name server, for the first client query on
that domain-of-interest. All subsequent queries within THAT
domain-of-interest, or for any OTHER domain-of-interest served on the same
name server, do not have a multiple RTT penalty.

This is absolutely not the case initially asserted, about adding "a
round-trip delay (a "synchronous binding check") to *every single DNS
delegation*". (emphasis added).

> domains.  Why is that OK for NS, A, and AAAA but not OK for SVCB?

Again, you are asserting facts not in evidence.
Not all delegations rely on A and AAAA records supplied as glue by the TLD.
Many do not.
In fact, I would assert that the opposite is the case: *most* do not.
Every delegation from every OTHER TLD to a name server whose name is in one
single TLD (such as "ns1.example.com") will be glueless.
And, a significant portion of same-TLD delegations are also glueless.
I know because we operate our name servers in a glueless manner, and those
by themselves represent a proportion close to the majority.
(If you want a count of records in a TLD, such as com, demonstrating
in-bailiwick counts vs glued non-in-bailiwick vs glueless non-in-bailiwick,
just ask, and I will try to get some. It might take a few days, though.)

This means that the TTLs on the A and AAAA records (plus any other possible
additional records) are under our direct control, not the control of the
parent TLDs. This would include SVCB (instantiated with some RRTYPE
specifically for this rather than using _NAME attrleaf), and TLSA records.

> limits on your DS updates, you should just omit it from the glue and pay

Again, and you seem not to be getting it, that 1-RTT addition only exists
(a) on first use, and (b) on RTT expiry, and then *only* for the first
client querying a domain served on the name server serving that domain,
and  *THEN* only if the resolver determines that it needs to perform the
query over TLS, including whether the authority server even offers TLS
resolution. If we can agree on the use of DNSSEC being mandated for this
ADoT stuff, a further short cut can be introduced by checking whether the
NS target is in a signed zone or not. This short cut is one argument in
favor of requiring DNSSEC for ADoT.

>>       - Different DNS Operator anycast instances may serve different
>>       TLSA records (geographically aligned values)
>>

You are arguing about someone else's infrastructure. Not your circus, not
your monkeys.

Also, ruling out someone else's operational practice as part of your
proposal for a standard, is not cool.

Your proposal is INCOMPATIBLE with this practice, so criticizing the
practice itself is using the "Wookie defence". Please don't do that.

> Yes!  That means that there is no rule here.  It is up to us.

No! It means it is up to the Registry Operators, the ICANN, the relevant
liasons, the IAB, the IESG, and all of the implementers and operators of
the DNS, and all of the applications which rely on the DNS (which is,
basically, everyone in the IETF, plus everyone not in the IETF).

The philosophy of "It is better to ask forgiveness than ask permission",
isn't something that extends well to multi-stakeholder environments.

I feel okay using a "DS hack" in the manner I have proposed, specifically
because:

   - It is proposed as a method to validate data ALREADY PUBLISHED AND USED
   IN DELEGATIONS (NS/A/AAAA)
   - The data proposed to be involved in validation IS ALREADY PRESENT, too
   (e.g. hashes of NS records, A glue records, AAAA glue records)
   - The mechanism could just as easily be implemented by Registries (doing
   the hash of the aforementioned records, since the Registries already have
   then on hand)
   - The EPP update sent by the child is a work-around unless/until
   Registries do this themselves
      - This would allow there to not need to be a flag day
      - Partial deployment of Registry-initiated DS records, would not
      preclude use in TLDs where that does not yet happen

> is entirely sufficient for this.

The assumptions needed for privacy, are that an on-path attacker cannot
unilaterally downgrade the connection, or more specifically, that no party
without control of the private key of the domain serving the name of the
name server, has the ability to signal that an insecure connection is okay.

If the signal is served from a signed domain operated by the party running
the name server (by way of the domain serving the name of the name server),
there is cryptographic protection on this signal.

If the signal is served by the parent, based on data supplied by
password-protected but not cryptographically protected channels, this is a
much weaker scenario.

The privacy "bill of goods" being sold in DPRIVE is that the query/response
are completely protected by PKI. If that PKI relies on a signal that is not
itself strongly protected, this is not meeting the intended goals of DPRIVE.

Arguing that the initial step of securing a domain (first DS to parent)
means nothing else needs to be as strong as what is provided by DNSSEC
after that DS is published in the parent, is a logical fallacy.

Improving the initial DS, and subsequent DS updates, is a related but
separate issue.

>> See above. The second bullet being glueless and the third being
>> glue-full, would mean the SVCB record would not have associated glue and
>> thus no v4 or v6 hints.
>>
>

What you don't follow is that there are non-in-bailiwick delegations, a lot
of them. The majority, possibly the vast majority.

Also, we are talking about DNS records for SVCB, i.e. "dot" with a
yet-to-be-specified binding analogous to HTTPS, with a default-alpn of
"port 53 UDP/TCP". The service name (owner name) can (and often will) exist
without corresponding A/AAAA records, and thus no *-hints parameters. In
fact, supplying hints would *break* resolution in many cases.

So, for purposes of providing a hypothetical concrete example, consider the
following records (at a TLD or at an authority server beneath that TLD):

In TLD "example"
foo.example NS ns1.dot-only.dns-operator.example
bar.example NS ns1.dot-allowed.dns-operator.example
blech.example NS ns1.no-dot.dns-operator.example

dns-operator.example NS ns1.dns-operator-server.example

In domain "dns-operator.example", served by ns1.dns-operator-server.example:
// SVCB type records with wildcards indicating what transports to
allow/offer:
$ORIGIN dns-operator.example.
*.dot-only DNS 1 "." no-default-alpn alpn="dot"
*.dot-allowed DNS 1 "." alpn="dot"
*.no-dot DNS 1 "."
* TLSA 2 1 1 ( fingerprint of intermediate signing cert for TLS certs used
on all DNS servers in this domain )

Given the use of DNSSEC, DANE, wildcard validation in DNSSEC, and
synthesized wildcard responses generated by resolvers, other than getting
the necessary A/AAAA records, all of the extra information required for
authenticated and downgrade-resistant ADoT (including signaling) is handled
by those four records.
The A/AAAA records were always needed for talking to the authoritative
servers, so the above are the only novel items.
All of these presume DNSSEC on the domain, and validation requires
obtaining the DS and DNSKEY records to bootstrap from a cold cache.

> same would be true of any DNSSEC implementation bug.)

More accurately, DNSSEC is built on the assumption that how records are
conveyed to the parent are out-of-scope. DNSSEC uses a security model that
assumes everything from that point on (the trust anchors and conveyance of
DS records existing and being trustworthy).

It has to work from that assumption to be possible to implement. Subject to
that assumption, DNSSEC is, itself, secure.

Those are not bugs. They are design deficiencies in the protocols used for
that conveyance.

Out of scope for the purposes of understanding DNSSEC, but not for adding
more things into the mix that themselves rely on the security of those
conveyances.

This is why limiting the "DS glue protection" to data already provided (but
not protected) makes sense, but doing anything to add more data and
assuming that it is safe and secure to do so, is questionable.

>> If the Registry's TLS connection was MITM'd by an on-path adversary with
>> a valid TLS cert issued by a different CA, which was in the trusted CA set

Excluding CAs from the trust model of DNS is definitely in-scope for DNS.

The option of resolvers using WebPKI is very different from relying on
WebPKI for secure DNS resolution (i.e. DNSSEC).

Having DNSSEC-signed records conveyed removes the need to rely on WebPKI as
part of the security chain for updating DNSSEC records.

DNSSEC is already required, so including reliance on that is a sensible
next step.

Allowing non-validated records sent over any channel, no matter how secure,
is less secure than using only validated records.

(This mirrors 5011, which itself could do with a -bis honestly.)

> delegated to a poorly chosen party, that is unfortunate, but we can't fix

The Registrar is only a necessary intermediary. The source of truth is the
Registrant (or possibly a delegated trusted party, the DNS Operator).
The lack of validation of the Registrant is the problem, not whether the
Registrar is trustworthy.

> registration (e.g. due to non-payment), so this cannot even offer full TOFU

Technically not true. Over-riding the NS is sufficient to break the
registration, and does not require any actions on the DS record itself.
(The EPP convention is that the Registrar can remove the DS, but that is a
different trust model than having the ability to change the DS.)

CDS provides a method for going insecure.

Multi-signer (being worked on) will likely need to address a number of
scenarios for allowing change-of-DNS-operator and change-of-Registrar
without going insecure.

Change of ownership of a secure domain absolutely will require going
insecure and doing a new bootstrap to secure, even if the old and new
owners use the same Registrar.

(Just stating facts.)

> I would welcome a draft addressing it, but I don't think it has anything
> to do with this discussion about authenticating delegation information.
>
>
>> They all rely on EPP, with no data integrity check on submitted DS
>> records associated with such CDS updates.
>>
>
> This does not seem like a fair description.  The Registrar is identified
> by a certificate issued by some mutually trusted authority, which signs a

TLS only provides channel integrity, not data origin integrity.

This is true for DoH/DoT as well, which is why most folks in DNSOP advocate
for DNSSEC validation even if the DNS queries are done over TLS.

>
>
>> The Registry can be completely trustworthy, but the weak link is
>> unchanged -- the Registrar-Registry update mechanism, which relies on
>> Registrar credentials.

I almost certainly will, or at least co-author such a draft.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Wed, 18 Aug 2021 15:29:27 -0400

> latency penalty for a cache miss would increase pressure to migrate to

As far as I am aware of, consolidation/centralization is only an issue when
talking about resolvers.

I'd be interested in pointers if consolidation by authority operators is a
privacy concern. Authority operators only see traffic from resolvers, not
from end users, and all of the data served is by definition public.

As far as is concerned with cold cache and long tail issues, there are
solutions that do not directly impact consolidation.
E.g. Operate a domain which serves the name of your name servers, on one or
more DNS hosting platforms. Put your A, AAAA, SVCB, TLSA records on that
server, which point everything at the actual name server you operate (not
hosted by anyone else). Most of the initial portions involved can be in a
warm cache. There is no way to eliminate the first A/AAAA lookup, unless
the domain-of-interest is fully glued in-bailiwick (which creates problems
for establishing a private channel for ADoT using signed TLSA records, i.e.
you can't without requiring the TLD to also provide other record types, or
relying on non-DNSSEC-signed validation of TLS, and being subject to
downgrade attacks.)

Brian

---

From: Joe Abley <[email-masked]>
Date: Wed, 18 Aug 2021 15:57:38 -0400

On Aug 18, 2021, at 15:29, Brian Dickson <[email-masked]> wrote:

> I'd be interested in pointers if consolidation by authority operators is a privacy concern. Authority operators only see traffic from resolvers, not from end users, and all of the data served is by definition public.

This is a bit of a tangent, but I think it's reasonable to say that it's not the public nature of the data being sent in responses that is the concern, it's the existence of any particular query and the data derived from that query's existence.

For example, Dave Dagon gave a good summary some years ago now about the disturbing number of resolvers that happily send host addresses in EDNS(0) client-subnet options to authoritative servers. I haven't seen current numbers, but I think it's perhaps reasonable to be open to the idea that authority servers acquire data from queries that identifies individuals, even if only in a minority of queries or if combined with some other dataset that maps personal identities to addresses.

The trick here is to be clear about what threat we are trying to mitigate so that we can understand the cost and the benefit, who should be able to choose to accept the cost and who benefits.

I have not been able to keep up with the thread I'm replying to in all its glory since I don't have enough hours in the day to dedicate to dnsop, but I think perhaps that this particular fragment of the discussion needs to distinguish between what nameservers are called and who runs them. Namespace consolidation intended to promote opportunities to return useful glue with responses and reduce the need to requery is not the same as one operator serving a large number of zones. A nameserver responding on a single address can be known by many names.

Joe

---

From: Peter Thomassen <[email-masked]>
Date: Thu, 19 Aug 2021 16:38:41 +0200

Hi Brian,

The proposal aims to authenticate parental NS and glue records by having the parent sign their hash digests, embedded in new types of DS records.

1.) The separation of the data which requires authentication (parental NS + glue records) from the place where authentication is provided can lead to a race condition: What happens if updates do the NS or glue records have been seen and cached by a resolver, but an old DS RRset is cached (or vice versa), so that digests mismatch? How does this interfere with the notion that it is acceptable to cache an RRset until its TTL expires?

2.) Conceptually, the goal of authenticating parental NS and glue records can also be achieved by signing them directly at the parent. In this case, the signature is bound directly to the data, and no race condition occurs. One may object that the parent is not authoritative, but that's merely a legalistic point: If we change the law and declare that the parent *can* sign these records, then authentication of parental NS and glue records would in fact be achieved. Thus my question -- why not pursue this route?

3.) Have any experiments been done to determine whether adding RRSIGs to parental NS and glue records breaks existing deployments? (Pointers welcome.)

Best,
Peter

On 8/12/21 3:15 AM, Brian Dickson wrote:
> https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt <https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt>
> 
> Brian
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 

-- 
Like our community service? 💛
Please consider donating at

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525

---

From: Brian Dickson <[email-masked]>
Date: Thu, 19 Aug 2021 13:57:47 -0400

On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen <[email-masked]> wrote:

> Hi Brian,
>
> The proposal aims to authenticate parental NS and glue records by having
> the parent sign their hash digests, embedded in new types of DS records.
>
> 1.) The separation of the data which requires authentication (parental NS
> + glue records) from the place where authentication is provided can lead to
> a race condition: What happens if updates do the NS or glue records have
> been seen and cached by a resolver, but an old DS RRset is cached (or vice
> versa), so that digests mismatch? How does this interfere with the notion
> that it is acceptable to cache an RRset until its TTL expires?
>

The process for changing glue or NS records is something that typically is
already dealt with by domain owners, by a sequence of changes and waiting
periods based on TTL.
(That generally involves changes to apex NS and delegation NS sets in a
specific order and involving waiting intervals based on TTL, as well as
having both sets of NS serving data during the change of NS.)

This would not be that different.
The general practice would be "make before break".
Add DS records to the set, wait, make the changes, wait, remove old DS
records that are no longer required.
This prevents the mismatches from happening, and is compatible with cache
assumptions regarding TTL.

> 2.) Conceptually, the goal of authenticating parental NS and glue records
> can also be achieved by signing them directly at the parent. In this case,
> the signature is bound directly to the data, and no race condition occurs.
> One may object that the parent is not authoritative, but that's merely a
> legalistic point: If we change the law and declare that the parent *can*
> sign these records, then authentication of parental NS and glue records
> would in fact be achieved. Thus my question -- why not pursue this route?
>

A number of reasons, including the answer to #3 below.
There is also the problem of backward compatibility during any deployment.
Whatever responses are returned by a TLD authority server for delegations,
would need to work with both existing resolvers and with updated resolvers.

Basically, my proposal is guaranteed to not break existing resolvers, and
to allow resolvers to use added records to add the functionality.
The other options are basically to use new RRTYPE(s), plus getting all the
TLDs to implement those unilateral changes on the parent side or to do #3
(see below for why not).
That is a long term solution, and the correct way to eventually deprecate
any hack.

So, the reason for my proposal is not to avoid doing new RRTYPEs, it is to
get something workable deployed on a faster timeline than decade(s).

The motivation is that there are missing parts needed for ADoT,
specifically validating NS delegations (NS names), needed for the
certificate name for TLS.

>
> 3.) Have any experiments been done to determine whether adding RRSIGs to
> parental NS and glue records breaks existing deployments? (Pointers
> welcome.)
>
>
I don't have pointers offhand, but yes, this has been experimented with, is
my understanding.
(Anyone have pointers? It might be nice to have them handy.)
The results and behavior may have varied, but were definitely not universal
success.
I'm not sure if some implementation combinations might have "worked", but
certainly not the majority of combinations.

Brian

> This is what has been described as a “hack”, but provides a needed
validation link for authoritative servers where the latter are in signed
zones, but where the served zones may not be signed.
> https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt <
https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt>

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany

---

From: Peter Thomassen <[email-masked]>
Date: Fri, 20 Aug 2021 15:23:36 +0200

On 8/19/21 7:57 PM, Brian Dickson wrote:
> 
> 
> On Thu, Aug 19, 2021 at 10:40 AM Peter Thomassen <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Brian,
> 
> The process for changing glue or NS records is something that typically is already dealt with by domain owners, by a sequence of changes and waiting periods based on TTL.
> (That generally involves changes to apex NS and delegation NS sets in a specific order and involving waiting intervals based on TTL, as well as having both sets of NS serving data during the change of NS.)
> 
> Add DS records to the set, wait, make the changes, wait, remove old DS records that are no longer required.
> This prevents the mismatches from happening, and is compatible with cache assumptions regarding TTL.

Right, that is obviously the right way to avoid the race condition. I had not thought of the fact that one can provision multiple DS glue records for the same algorithm (but yes, it's just as with any other algorithm), and I think it should be mentioned in the draft.

Some follow-up thoughts:

a) If the parent is charged with computing and maintaining DS glue (i.e. the registrant does nothing new), then the parent will have to take care that the double-provisioning and clean-up is happening, while adhering to various waiting times. This requires keeping state on the parental side that previously did not have to be kept. Has this been considered?

b) If the parent is *not* charged with computing and maintaining DS glue, then the registrant has to do it. Registrants often are already overburdened with uploading regular DS records, not to mention following a specifically timed DS update producure when all they want is add an A glue record. While this is not a problem for ADoT, I think it can be expected that the vast majority of registrations, even if the delegation and child zone use DNSSEC, will not get secured with DS glue, and not receive any of the benefits of glue authentication.

As a consequence, one either has to (a) get the parent involved significantly, or (b) the privacy goal of preventing the qname leaking to bogus authoritative nameserver will not be met, and the mechanism is effectively reduced to an ADoT enabler (no offense intended, using pointed language only to dig deeper and spark good discussion).

Do you share this asseessment?

(I am not making a statement on the significance of the qname leak privacy issue, but my understanding is that preventing that leak is one of the goals of the protocol -- I may be mistaken.)

> I don't have pointers offhand, but yes, this has been experimented with, is my understanding.
> The results and behavior may have varied, but were definitely not universal success.
> I'm not sure if some implementation combinations might have "worked", but certainly not the majority of combinations.

I really would like to learn of some instances where things went wrong (and then look into what went wrong). Perhaps someone knows?

Best,
Peter

>  > https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt <https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt> <https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt <https://www.ietf.org/archive/id/draft-dickson-dnsop-ds-hack-00.txt>>
>  >
>  > Brian
>  >
>  > [email-masked] <mailto:[email-masked]>
>  > https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>  >
> 
> -- 
> https://desec.io/ <https://desec.io/>
> 
> deSEC e.V.
> Kyffhäuserstr. 5
> 10781 Berlin
> Germany
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 

https://desec.io/

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany