Subject: [DNSOP] CNSRRSIG (was: Re: [Ext] draft-fujiwara-dnsop-delegation-information-signer))

From: Peter van Dijk <[email-masked]>
Date: Thu, 10 Dec 2020 22:19:00 +0100

Hello Paul,

On Mon, 2020-11-30 at 15:43 +0000, Paul Hoffman wrote:
> The more I think about draft-fujiwara-dnsop-delegation-information-signer, the more I think that it is much more complex than what we are doing now in DNSSEC, and therefore undesirable.

My feelings are similar but not identical - the conversation already
shows that the glue story will be almost impossible to implement. Next
to that, I haven't figured out why we'd want to authenticate glue.
However, authenticating the delegation NSset fills an obvious gap in
various suggested answers to the dprive phase2 question (privacy
between resolvers and authoritatives).

> If the goal is "a way for a signer in a parent to sign child NS in a way that does not affect validators that have not been updated (or don't care)", a significantly easier solution would be a new RRtype (maybe called "CNSRRSIG") that closely mimics RRSIG but only allows child NS for signing. An aware signer included the CNSRRSIG in the zone, and an aware authoritative server includes in in the Authority section when serving child NS records. An aware resolver can use this, an unware resolver would treat it like any other unknown RRtype that appears in the Authority section.

This makes a ton of sense to me.

Compared to DiS, registrar complexity is identical (because the
complexity is also hidden in the signer here); signer complexity is
potentially lower. The only real complexity change vs. DiS is in the
auths, that now need to know to serve CNSRRSIG from the parent side in
the additional part of a delegation response. For resolvers, this vs.
DiS is again pretty much moot.

> There are probably a few other diffs from the RRSIG definition in RFC 403x, but they should be minor. This might make implementation more likely to be correct for signers, servers, and resolvers.

Yes, this calls for some experiments, but I suspect the outcome will be
as you described above - which means no hurdles to incremental rollout.

(I am not even convinced this needs to be a new type, vs. reusing RRSIG
under the specific semantics you described, but a new type feels
cleaner to me.)

> Thoughts?

+1 !

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

---

From: Brian Dickson <[email-masked]>
Date: Thu, 10 Dec 2020 15:48:07 -0800

On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk <[email-masked]>
wrote:

> > The more I think about
> draft-fujiwara-dnsop-delegation-information-signer, the more I think that
> it is much more complex than what we are doing now in DNSSEC, and therefore
> undesirable.
>
> > If the goal is "a way for a signer in a parent to sign child NS in a way
> that does not affect validators that have not been updated (or don't
> care)", a significantly easier solution would be a new RRtype (maybe called
> "CNSRRSIG") that closely mimics RRSIG but only allows child NS for signing.
> An aware signer included the CNSRRSIG in the zone, and an aware
> authoritative server includes in in the Authority section when serving
> child NS records. An aware resolver can use this, an unware resolver would
> treat it like any other unknown RRtype that appears in the Authority
> section.
>
>
I think this is close to the mark, but still slightly off.
My take on this is roughly as follows:

   - The goal here (as I understand it, or perhaps how I interpret it) is
   to have NS data, corresponding to the child apex NS set, published on the
   parent zone and signed by the parent (and used by upgraded resolvers
   without breaking anything not upgraded).
   - This involves at minimum the following elements, presented in a kind
   of "reverse Polish" order:
      - An RRSIG (or RRSIG-like thing) in the parent zone over something
      new (TBD1)
      - A way of publishing that "something new" to the parent (TBD2)
      - A way of authenticating/validating that "something new" in the
      process of publishing to the parent (TBD3)
      - A way of linking the published "authenticating/validating" data
      with data signed in the child zone, when being used/validated by the
      resolver (or client) (TBD4)
   - For "TBD1" If we keep the existing RRSIG signatures themselves, the
   only question is when to include the "something new" in the delegation
   response, along with the matching RRSIG.
      - This suggests no need for a new RRSIG-like record type per se.
      - Existing 403x/5155 logic handles adding RRSIGs to answers
   - For "TBD2", the concern over what "something new" could be, and how it
   gets published to the parent.
      - Options to consider for "something new" itself are:
         - A new RRTYPE with owner name of "apex"
         - An existing RRTYPE with owner name of "apex", with new parameters
         - An existing RRTYPE with different owner name
         - (For completeness, A new RRTYPE with different owner name)
      - Options to consider for "how it gets published" are basically:
         - EPP
         - This suggests the fewer "new" things involved, the better. Zero
         new things would be ideal.
      - This itself leads to preference for "An existing RRTYPE with owner
      name of 'apex', with new parameters", specifically:
         - Published RRTYPE == DS
         - DS value is hash of DNSKEY with new parameters, specifically a
         new algorithm
         - The new algorithm is "concatenation of child apex NS RRSET in
         canonical form and order" (i.e. that is what the DNSKEY
'public key' field
         would be comprised of)
         - NB: The existing specifications handle this -- new (unknown)
         algorithms MUST be treated as if the record didn't exist.
            - Some implementations may need to be fixed, based on some
            experiments thus far.
         - I think TBD3 and TBD4 are flip sides of the same coin.
      - RRTYPE == DNSKEY or DS (depending on TLD) transferred via EPP to
      the parent
      - If RRTYPE transferred is DNSKEY, perform hash to produce DS.
      - TBD3 is probably optional as it related to EPP
      - TBD4 is the resolver/client validation, in two parts:
         - Construct DNSKEY from input data (NS RRSET)
         - Hash to create DS
         - Compare to published DS
         - Check RRSIG over DS
      - The use case of getting the glue (and validating it) without
   actually sending queries to the auth server itself prior to validating the
   glue, is a classic "catch 22". The owner name of the NS set in the child
   zone, is "privacy sensitive", at least in most use cases. However:
      - Keeping the apex and delegation NS set in sync, and the DNSKEY and
      DS in sync, can address this problem:
         - Use CDS/CDNSKEY to publish DS/DNSKEY records that match the
         current AND updated NS RRSET, prior to changing the NS RRSET
         - Use the *delegation* NS RRSET rather than the *child* apex NS
         RRSET for the validation (ie for recreation of DNSKEY and DS records)
         - This would add extra steps when changing NS, but would still be
         deterministic and possible to build into a state machine,
with an extra
         moving part (or two)
         - It would then be feasible to get validated glue prior to
         querying the authority server (e.g. for its TLSA record) and/or to
         establish a TLS connection to the correct IP and name.

The TL;DR: of this is: no EPP changes needed, no new RRTYPEs needed,
slightly more steps in rolling the NS set during a change.

> DiS is again pretty much moot.

The CNSRRSIG would also require delegation auths (i.e. TLDs) to make
changes, and I think also require EPP changes.
See above for a very slightly different take on this idea, that avoids
these issues.
(EPP and TLDs are definitely the "long pole in the tent".)

>
> > There are probably a few other diffs from the RRSIG definition in RFC
> 403x, but they should be minor. This might make implementation more likely
> to be correct for signers, servers, and resolvers.
>

+1 for me too.

Brian

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Dec 2020 11:14:13 +1100

Before going on I would really like to know what operational problem is being
attempted to be solved by signing delegating information?

Fujiwara-san has presented the draft without specifying what problem it is
attempting to solve.  The fact the records are not signed is a observation
not a problem per say.

Mark

> On 11 Dec 2020, at 10:48, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> On Thu, Dec 10, 2020 at 1:19 PM Peter van Dijk <[email-masked]> wrote:
> Hello Paul,
> 
> 	• The goal here (as I understand it, or perhaps how I interpret it) is to have NS data, corresponding to the child apex NS set, published on the parent zone and signed by the parent (and used by upgraded resolvers without breaking anything not upgraded).
> 	• This involves at minimum the following elements, presented in a kind of "reverse Polish" order:
> 		• An RRSIG (or RRSIG-like thing) in the parent zone over something new (TBD1)
> 		• A way of publishing that "something new" to the parent (TBD2)
> 		• A way of authenticating/validating that "something new" in the process of publishing to the parent (TBD3)
> 		• A way of linking the published "authenticating/validating" data with data signed in the child zone, when being used/validated by the resolver (or client) (TBD4)
> 	• For "TBD1" If we keep the existing RRSIG signatures themselves, the only question is when to include the "something new" in the delegation response, along with the matching RRSIG. 
> 		• This suggests no need for a new RRSIG-like record type per se.
> 		• Existing 403x/5155 logic handles adding RRSIGs to answers
> 	• For "TBD2", the concern over what "something new" could be, and how it gets published to the parent. 
> 		• Options to consider for "something new" itself are:
> 			• A new RRTYPE with owner name of "apex"
> 			• An existing RRTYPE with owner name of "apex", with new parameters
> 			• An existing RRTYPE with different owner name
> 			• (For completeness, A new RRTYPE with different owner name)
> 		• Options to consider for "how it gets published" are basically:
> 			• EPP
> 			• This suggests the fewer "new" things involved, the better. Zero new things would be ideal.
> 		• This itself leads to preference for "An existing RRTYPE with owner name of 'apex', with new parameters", specifically:
> 			• Published RRTYPE == DS
> 			• DS value is hash of DNSKEY with new parameters, specifically a new algorithm
> 			• The new algorithm is "concatenation of child apex NS RRSET in canonical form and order" (i.e. that is what the DNSKEY 'public key' field would be comprised of)
> 			• NB: The existing specifications handle this -- new (unknown) algorithms MUST be treated as if the record didn't exist. 
> 				• Some implementations may need to be fixed, based on some experiments thus far.
> 	• I think TBD3 and TBD4 are flip sides of the same coin.
> 		• RRTYPE == DNSKEY or DS (depending on TLD) transferred via EPP to the parent
> 		• If RRTYPE transferred is DNSKEY, perform hash to produce DS.
> 		• TBD3 is probably optional as it related to EPP
> 		• TBD4 is the resolver/client validation, in two parts:
> 			• Construct DNSKEY from input data (NS RRSET)
> 			• Hash to create DS
> 			• Compare to published DS
> 			• Check RRSIG over DS
> 	• The use case of getting the glue (and validating it) without actually sending queries to the auth server itself prior to validating the glue, is a classic "catch 22". The owner name of the NS set in the child zone, is "privacy sensitive", at least in most use cases. However:
> 		• Keeping the apex and delegation NS set in sync, and the DNSKEY and DS in sync, can address this problem:
> 			• Use CDS/CDNSKEY to publish DS/DNSKEY records that match the current AND updated NS RRSET, prior to changing the NS RRSET
> 			• Use the delegation NS RRSET rather than the child apex NS RRSET for the validation (ie for recreation of DNSKEY and DS records)
> 			• This would add extra steps when changing NS, but would still be deterministic and possible to build into a state machine, with an extra moving part (or two)
> 			• It would then be feasible to get validated glue prior to querying the authority server (e.g. for its TLSA record) and/or to establish a TLS connection to the correct IP and name.
> The TL;DR: of this is: no EPP changes needed, no new RRTYPEs needed, slightly more steps in rolling the NS set during a change.
>  
> The CNSRRSIG would also require delegation auths (i.e. TLDs) to make changes, and I think also require EPP changes.
> See above for a very slightly different take on this idea, that avoids these issues.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Dec 2020 19:22:35 -0500

> attempted to be solved by signing delegating information?

+1

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2020 00:25:03 +0000

> attempting to solve.  The fact the records are not signed is a observation

Asking for stated use cases! Yay!

In DPRIVE, there is a desire to TLSA records to authenticate authoritative servers. In order to do that without getting into a chicken-and-egg loop, the parent needs to authenticate the NS records of the child authoritative server.

If child NS records were already signed in the parent, that solves this use case. They aren't, so we're thinking of ways to authenticate child NS records from the parent.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Dec 2020 19:35:12 -0500

> In DPRIVE, there is a desire to TLSA records to authenticate authoritative servers. In order to do that without getting into a chicken-and-egg loop, the parent needs to authenticate the NS records…

I haven't been following dprive recently. Is there a particular document that expresses the problem statement above in more detail?

"Authenticate authoritative servers" is a bit vague for me. Parent and child are namespace concepts and not relying parties that you'd ordinarily expect to be able to authenticate anything.

Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2020 00:41:34 +0000

> I haven't been following dprive recently. Is there a particular document that expresses the problem statement above in more detail?

No. As you know, DPRIVE is not strong on use case documents...

> "Authenticate authoritative servers" is a bit vague for me. Parent and child are namespace concepts and not relying parties that you'd ordinarily expect to be able to authenticate anything.

A resolver asks a parent what the NS records are for the child. Today, an on-path attacker can change the answer and the resolver would not be the wiser, so the resolvers cannot trust such answers to do things like look up TLSA records. There is a desire for resolvers to be sure that what the child NS records they receive from the parent is what the parent has in its zone for the child so they can use this information to ask for TLSA records.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Thu, 10 Dec 2020 19:52:15 -0500

> A resolver asks a parent what the NS records are for the child. Today, an on-path attacker can change the answer and the resolver would not be the wiser, so the resolvers cannot trust such answers…

The problems that DNSSEC is trying to solve are with identifying inauthentic data ultimately requested by applications. If an intermediate referral response includes an inauthentic NS RRSet with no RRSIGs it cannot be identified as inauthentic, but it doesn't really matter because any data that is expected to be signed from the inauthentic servers will fail validation and the application will be protected.

The problems that dprive is trying to solve concern surveillance opportunities and information leakage. that if an imtermediate referral response includes an inauthentic NS RRSet with no RRSIGs it could cause queries on behalf of an application to be harvested by an untrusted third party at one of those inauthentic servers, which could represent a surveillance opportunity.

The proposal is hence to provide a way for an intermediate referral response that includes an inauthentic NS RRSet to be identified as inauthentic so that subsequent queries to the untrusted third party servers can be suppressed.

Did I read that back correctly?

I've now typed "inauthentic" enough that I am starting to doubt that it is a word, but "bogus" has a particular and different meaning in DNSSEC so I was trying to avoid it.

Joe

---

From: Brian Dickson <[email-masked]>
Date: Thu, 10 Dec 2020 17:21:07 -0800

On Thu, Dec 10, 2020 at 4:52 PM Joe Abley <[email-masked]> wrote:

> >> "Authenticate authoritative servers" is a bit vague for me. Parent and
> child are namespace concepts and not relying parties that you'd ordinarily
> expect to be able to authenticate anything.
> >
> > A resolver asks a parent what the NS records are for the child. Today,
> an on-path attacker can change the answer and the resolver would not be the
> wiser, so the resolvers cannot trust such answers to do things like look up
> TLSA records. There is a desire for resolvers to be sure that what the
> child NS records they receive from the parent is what the parent has in its
> zone for the child so they can use this information to ask for TLSA records.
>
> The problems that DNSSEC is trying to solve are with identifying
> inauthentic data ultimately requested by applications. If an intermediate
> referral response includes an inauthentic NS RRSet with no RRSIGs it cannot
> be identified as inauthentic, but it doesn't really matter because any data
> that is expected to be signed from the inauthentic servers will fail
> validation and the application will be protected.
>
> The problems that dprive is trying to solve concern surveillance
> opportunities and information leakage. that if an imtermediate referral
> response includes an inauthentic NS RRSet with no RRSIGs it could cause
> queries on behalf of an application to be harvested by an untrusted third
> party at one of those inauthentic servers, which could represent a
> surveillance opportunity.
>
> The proposal is hence to provide a way for an intermediate referral
> response that includes an inauthentic NS RRSet to be identified as
> inauthentic so that subsequent queries to the untrusted third party servers
> can be suppressed.
>
Yes.

Brian

> I've now typed "inauthentic" enough that I am starting to doubt that it is
> a word, but "bogus" has a particular and different meaning in DNSSEC so I
> was trying to avoid it.
>
>
> Joe

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Dec 2020 01:49:00 +0000

> Did I read that back correctly?

Somewhat, but not completely.

> The problems that DNSSEC is trying to solve are with identifying inauthentic data ultimately requested by applications. If an intermediate referral response includes an inauthentic NS RRSet with no RRSIGs

or an NS RRset with bogus RRSIGs

> it cannot be identified as inauthentic, but it doesn't really matter because any data that is expected to be signed from the inauthentic servers will fail validation and the application will be protected.
> 

That is true so far, but some folks have informally gotten excited about authenticating intermediate referral responses for other reasons. (They can speak for themselves; that's not my use case yet.)

> The proposal is hence to provide a way for an intermediate referral response that includes an inauthentic NS RRSet to be identified as inauthentic so that subsequent queries to the untrusted third…

Again, this is true so far, but others have hinted that they might use the authentication for more.

> I've now typed "inauthentic" enough that I am starting to doubt that it is a word, but "bogus" has a particular and different meaning in DNSSEC so I was trying to avoid it.

You even skipped using "bogus" once above. :-)

--Paul Hoffman