Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews > 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 ? > From: Mark Andrews >> 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. 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 > 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. 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 > the child is unsigned, then restart following the referral. This is a lot > of work for very little benefit. 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? > 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 would like to read such draft (idea). > 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 they don't share authoritative servers, referrals (NS RRSet and glue) are uniquely determined. >> 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. Yes. I agree. It's another discussion. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> On 4 Nov 2020, at 15:31, fujiw...@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 > > ___ > 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: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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, fujiw...@jprs.co.jp wrote: > > >> >> From: Mark Andrews 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 >> 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) > > Do you mean these 2 lines in example.net zone ? >>child.example.net NS a.sub.child.example.net >>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. > > -- > Kazunori Fujiwara, JPRS > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews >>> 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 > 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) Do you mean these 2 lines in example.net zone ? > child.example.net NS a.sub.child.example.net > 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. -- Kazunori Fujiwara, JPRS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> On 5 Nov 2020, at 15:49, fujiw...@jprs.co.jp wrote: > >> From: Mark Andrews >> 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 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) > > "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/ from root (or child.exapmle.net). > > Then I think the idea works. > > -- > Kazunori Fujiwara, JPRS > >>> On 4 Nov 2020, at 15:31, fujiw...@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 ? >>> >>> 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 >>> >>> ___ >>> 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: ma...@isc.org >> >> -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Mark Andrews > 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 "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/ from root (or child.exapmle.net). Then I think the idea works. -- Kazunori Fujiwara, JPRS >> On 4 Nov 2020, at 15:31, fujiw...@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 ? >> >> 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 >> >> ___ >> 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: ma...@isc.org > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
> From: Bob Harold > 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. 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 0 0 100 (hash of (example.com IN NS | ns.example.com IN )) 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). -- Kazunori Fujiwara, JPRS > -- > Bob Harold > DNS and DHCP Hostmaster - UMNet > Information and Technology Services (ITS) > rharo...@umich.edu 734-512-7038 > > > On Tue, Nov 3, 2020 at 11:31 PM 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 ? >> >> 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 >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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, fujiw...@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 ? > > 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 > > ___ > 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: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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) rharo...@umich.edu 734-512-7038 On Tue, Nov 3, 2020 at 11:31 PM 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 ? > > 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 > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-fujiwara-dnsop-delegation-information-signer
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
