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

> On 4 Nov 2020, at 15:31, fujiwara@jprs.co.jp wrote:
> 
> 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 ?

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.

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

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.

> If someone interested the document, I would like time slot at dnsop WG
> meeting.
> 
> Regards,
> 
> --
> Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org