Subject: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer

From: [email-masked]
Date: Wed, 04 Nov 2020 13:31:37 +0900 (JST)

I submitted draft-fujiwara-dnsop-delegation-information-signer-00.

Name:		draft-fujiwara-dnsop-delegation-information-signer
Revision:	00
Title:		Delegation Information (Referrals) Signer for DNSSEC
Document date:	2020-11-03
Group:		Individual Submission
Pages:		6
URL:            https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt

DNSSEC does not have a function to validate delegation information.
I think it is a large missing peace of DNSSEC.

I have a question why we did not include signature validation function
to delegation information ?

Probably, because it is non-authoritative information.
Or, because it was difficult to define the necessary and sufficient
delegation information.

It is now widely agreed (although not explicitly documented) that the
delegation information is the information used for name resolution and
does not result in name resolution.

We have a word "in-domain" glue which is the necessary and sufficient glue.

And the idea may offer the signature for root priming data.

If someone interested the document, I would like time slot at dnsop WG
meeting.

Regards,

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

---

From: Bob Harold <[email-masked]>
Date: Wed, 4 Nov 2020 11:10:45 -0500

If an attacker is spoofing responses, it seems that they could send a
different NS and A record, and a new calculated DS hash.  So this provides
no protection against spoofing?

We would need instead (or in addition) an RRSIG record to actually protect
this.

An example would help.

-- 
Bob Harold
DNS and DHCP Hostmaster - UMNet
Information and Technology Services (ITS)
[email-masked]   734-512-7038

On Tue, Nov 3, 2020 at 11:31 PM <[email-masked]> wrote:

> URL:
> https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Mark Andrews <[email-masked]>
Date: Thu, 5 Nov 2020 14:00:30 +1100

One problem with DiS is that assumes that address records in the additional
section *always* come from the delegating zone (see how the hash is created).
This is not how DNS works.  Address records can, correctly, come from other
sources, even when the name is *below* the zone cut.

Take a server that serves example.net and sub.child.example.net.  That A record
comes from sub.child.example.net not example.net when the name of the server is
a.sub.example.net.

	child.example.net NS a.sub.example.net
	a.sub.example.net A 1.2.3.4

Mark

> On 4 Nov 2020, at 15:31, [email-masked] wrote:
> 

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

---

From: [email-masked]
Date: Thu, 05 Nov 2020 13:40:05 +0900 (JST)

> From: Bob Harold <[email-masked]>

Thanks for reading the draft.

I'm assuming that DiS RR is treated as the DS RR, so if the parent
side is signed, DS (+DiS) RRSet will be signed.

> An example would help.

Yes. I will add examples in next version.

example.com.    IN NS ns.example.com.
ns.example.com. IN A 2001:dc8::53
example.com.    IN DS 12345 8 2 (hash of DNSKEY RR)
example.com.    IN DS 00000 0 100 (hash of (example.com IN NS | ns.example.com IN AAAA))
example.com.    IN RRSIG DS (signature of DS RRSet (2 DSes))

DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR).

---

From: [email-masked]
Date: Thu, 05 Nov 2020 13:49:45 +0900 (JST)

> From: Mark Andrews <[email-masked]>

"a.sub.example.net" is not a "in-domain" glue. (it is "sibling" glue).
Then, DiS RR for child.example.net will be generated
from "child.example.net NS a.sub.example.net".

Authoritative server of "child.example.net" responds
  child.example.net NS a.sub.example.net in authority section
  with/without a.sub.example.net A 1.2.3.4 as a glue in additional section.

Sibling glue "a.sub.example.net A 1.2.3.4" is not a target of DiS RR
for "child.example.net NS".
Validator can validate "child.example.net NS a.sub.example.net".

Validating resolver can accept the sibling glue "a.sub.example.net A 1.2.3.4".
Or,
validating resolver may reject the sibling glue "a.sub.example.net A 1.2.3.4",
and treat it similar to out-of-bailing domain name,
then, resolve "a.sub.example.net" A/AAAA from root (or child.exapmle.net).

Then I think the idea works.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 5 Nov 2020 15:54:18 +1100

> On 5 Nov 2020, at 15:49, [email-masked] wrote:
> 

I ment
	child.example.net NS a.sub.child.example.net
	a.sub.child.example.net A 1.2.3.4

(which should have been obvious from the paragraph above)

---

From: [email-masked]
Date: Thu, 05 Nov 2020 17:26:35 +0900 (JST)

> (which should have been obvious from the paragraph above)

Do you mean these 2 lines in example.net zone ?
> 	a.sub.child.example.net A 1.2.3.4

Then, we can generate DiS RR.
  hash ( child.example.net NS | a.sub.child.example.net A).

DNSSEC validators can get both "child.example.net NS a.sub.child.example.net"
and glue "a.sub.child.example.net A 1.2.3.4",
and validate child.example.net DiS RR.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Nov 2020 09:10:41 +1100

DNS is loosely coherent. DiS does not work when the sources of data are not coherent. 

-- 
Mark Andrews

> On 5 Nov 2020, at 19:26, [email-masked] wrote:
> 
> 
>>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 6 Nov 2020 10:39:22 +1100

> to delegation information ?

Delegating NS records because the zone would become big and people didn’t
want to have TLD zones have signatures for each delegation.  We could sign
delegating NS records as you can determine delegating vs top of zone by
looking at the signer field of the NS RRset.  You would then have to deal
with the case where you have signed parent and unsigned child and a referral
to the grand child.  You would have to stop following the referral, verify
the child is unsigned, then restart following the referral.  This is a lot
of work for very little benefit.

Glue records would need a different signature type and would need to compute
the signature differently to prevent it being used in a replay attack when
the RRset differ. I suppose you could use the same algorithm as it would
encourage people to keep data coherent. You would still have the parent,
child, grandchild issues from above.

If one wants to stop spoofed referrals being accepted do something like
well known TSIG which will stop off path spoofed traffic dead.  It will
also stop off path reassembly attacks dead as the spoofed reassembled
packet will be rejected.  On path attackers can just race the server
without DNSSEC.

Chairs, can you issue a call for WG adoption of my well known TSIG
draft please.
 
> And the idea may offer the signature for root priming data.

It can’t.  There is no requirement for addresses records for nameservers
for a zone to exist in the zone, as glue or not, even if the nameservers
are below top of zone.  Glue is only required for delegations.

---

From: [email-masked]
Date: Thu, 12 Nov 2020 18:31:33 +0900 (JST)

> DNS is loosely coherent. DiS does not work when the sources of data are not coherent. 

Do you mean that the glue is not uniquely determined because the
authoritative server merges multiple zone information or the data
cached by the resolver part of the DNS server ?

> want to have TLD zones have signatures for each delegation.

  In case of TLDs with many signed (with DS) delegations, the increase
  of DiS RR is not a problem because DiS is a part of DS RRSet.

> We could sign
> to the grand child.

Do you mean that digest calculation is difficult because RRSets with
the same name come from servers in multiple layers and are mixed?

> You would have to stop following the referral, verify

many domains are 3 layered.

root: signed  (with signed referrals)
TLD:  signed  (with signed referrals)
example.com: unsigned (no referral)

Then, example.com can't be validated, but at least it's nice to know
that the referral from the TLD is correct?

> the RRset differ.

I would like to read such draft (idea).

> I suppose you could use the same algorithm as it would

If they don't share authoritative servers,
referrals (NS RRSet and glue) are uniquely determined.

> are below top of zone.  Glue is only required for delegations.

Yes. I agree. It's another discussion.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 30 Nov 2020 15:43:22 +0000

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.

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.

Thoughts?

--Paul Hoffman