DS record RRSIG
This may not be the right place to ask, if this is a better question asked in a different list, please let me know. I am curious as to how BIND generates and processes DS RRSIG, and this may not be unique to BIND, since I've seen this behavior across multiple vendors. From the following: $ dig example.com. DS +dnssec +nocrypto ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;example.com. IN DS ;; ANSWER SECTION: example.com. 84558 IN DS 43547 8 2 [omitted] example.com. 84558 IN DS 31406 8 1 [omitted] example.com. 84558 IN DS 31406 8 2 [omitted] example.com. 84558 IN DS 31589 8 1 [omitted] example.com. 84558 IN DS 31589 8 2 [omitted] example.com. 84558 IN DS 43547 8 1 [omitted] example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 20190702031256 3800 com. [omitted] ;; Query time: 228 msec ;; SERVER: 10.0.22.1#53(10.0.22.1) ;; WHEN: Wed Jul 03 01:27:42 PST 2019 ;; MSG SIZE rcvd: 455 There are 6 DS records total, but only 1 RRSIG. This leads me to believe that the single RRSIG is generated by somehow concatenating all DS records together. This then leads me to believe that the validating resolver needs to process _all_ DS records, not just the ones whose key tag matches the child zone's KSK. Is this true? It seems like a small overhead in the grand scheme of things, but that seems inefficient, if multiple DS records are left at the parent zone after a couple of key rollovers. Any information on this would be appreciated. -Josh ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Yes, the whole RRSet is always signed. Signing individual records would not protect against attacks stripping individual records and their RRSIGs. Ondrej -- Ondřej Surý ond...@isc.org > On 2 Jul 2019, at 19:34, Josh Kuo wrote: > > This may not be the right place to ask, if this is a better question asked in > a different list, please let me know. > > I am curious as to how BIND generates and processes DS RRSIG, and this may > not be unique to BIND, since I've seen this behavior across multiple vendors. > From the following: > > $ dig example.com. DS +dnssec +nocrypto > > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags: do; udp: 4096 > ;; QUESTION SECTION: > ;example.com. IN DS > > ;; ANSWER SECTION: > example.com. 84558 IN DS 43547 8 2 [omitted] > example.com. 84558 IN DS 31406 8 1 [omitted] > example.com. 84558 IN DS 31406 8 2 [omitted] > example.com. 84558 IN DS 31589 8 1 [omitted] > example.com. 84558 IN DS 31589 8 2 [omitted] > example.com. 84558 IN DS 43547 8 1 [omitted] > example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 > 20190702031256 3800 com. [omitted] > > ;; Query time: 228 msec > ;; SERVER: 10.0.22.1#53(10.0.22.1) > ;; WHEN: Wed Jul 03 01:27:42 PST 2019 > ;; MSG SIZE rcvd: 455 > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe that > the single RRSIG is generated by somehow concatenating all DS records > together. This then leads me to believe that the validating resolver needs to > process _all_ DS records, not just the ones whose key tag matches the child > zone's KSK. Is this true? It seems like a small overhead in the grand scheme > of things, but that seems inefficient, if multiple DS records are left at the > parent zone after a couple of key rollovers. > > Any information on this would be appreciated. > > -Josh > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Thank you for the clarification. On Wed, Jul 3, 2019 at 1:49 AM Ondřej Surý wrote: > Yes, the whole RRSet is always signed. Signing individual records would > not protect against attacks stripping individual records and their RRSIGs. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 2 Jul 2019, at 19:34, Josh Kuo wrote: > > > > This may not be the right place to ask, if this is a better question > asked in a different list, please let me know. > > > > I am curious as to how BIND generates and processes DS RRSIG, and this > may not be unique to BIND, since I've seen this behavior across multiple > vendors. From the following: > > > > $ dig example.com. DS +dnssec +nocrypto > > > > ; <<>> DiG 9.12.2-P2 <<>> example.com. DS +dnssec +nocrypto > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48102 > > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 4096 > > ;; QUESTION SECTION: > > ;example.com. IN DS > > > > ;; ANSWER SECTION: > > example.com. 84558 IN DS 43547 8 2 [omitted] > > example.com. 84558 IN DS 31406 8 1 [omitted] > > example.com. 84558 IN DS 31406 8 2 [omitted] > > example.com. 84558 IN DS 31589 8 1 [omitted] > > example.com. 84558 IN DS 31589 8 2 [omitted] > > example.com. 84558 IN DS 43547 8 1 [omitted] > > example.com. 84558 IN RRSIG DS 8 2 86400 20190709042256 > 20190702031256 3800 com. [omitted] > > > > ;; Query time: 228 msec > > ;; SERVER: 10.0.22.1#53(10.0.22.1) > > ;; WHEN: Wed Jul 03 01:27:42 PST 2019 > > ;; MSG SIZE rcvd: 455 > > > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > that the single RRSIG is generated by somehow concatenating all DS records > together. This then leads me to believe that the validating resolver needs > to process _all_ DS records, not just the ones whose key tag matches the > child zone's KSK. Is this true? It seems like a small overhead in the grand > scheme of things, but that seems inefficient, if multiple DS records are > left at the parent zone after a couple of key rollovers. > > > > Any information on this would be appreciated. > > > > -Josh > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users > > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Josh Kuo wrote: > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > that the single RRSIG is generated by somehow concatenating all DS records > together. Correct. > This then leads me to believe that the validating resolver needs to > process _all_ DS records, not just the ones whose key tag matches the > child zone's KSK. Not quite. One way to validate a delegation is: * validate the DS RRset, which is signed using the parent's DNSKEY(s) [ you can see the "com" signer field in the "example.com" RRSIG ] * get the key tags from the DS RRset (the first field in the records) and the key tags from the child's DNSKEY RRSIG records (between lifetime fields and the signer field) and calculate the key tags of the child's DNSKEY records * take the intersection of these three sets; these key tags identify keys that the parent says can validate the DNSKEY RRset, and that actually do validate the DNSKEY RRset, and that can be used to validate the DNSKEY RRset * for each DNSKEY in the set, ensure that there is a DS record that whose digest matches it [ you can skip matching attempts when the key tags do not match ] * using the public keys and signatures you just identified, try to validate the self-signature on the DNSKEY RRset; if any of the signatures validates, it's all good! [ again the key tags let you skip pointless signature validation attempts ] There are some extra complications to do with downgrade protection, but that's the basic idea. Tony. -- f.anthony.n.finchhttp://dotat.at/ women and men working together ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DS record RRSIG
Tony, Thank you for that detailed explanation. On Wed, Jul 3, 2019 at 2:15 AM Tony Finch wrote: > Josh Kuo wrote: > > > > There are 6 DS records total, but only 1 RRSIG. This leads me to believe > > that the single RRSIG is generated by somehow concatenating all DS > records > > together. > > Correct. > > > This then leads me to believe that the validating resolver needs to > > process _all_ DS records, not just the ones whose key tag matches the > > child zone's KSK. > > Not quite. > > One way to validate a delegation is: > > * validate the DS RRset, which is signed using the parent's DNSKEY(s) > [ you can see the "com" signer field in the "example.com" RRSIG ] > > * get the key tags from the DS RRset (the first field in the records) > and the key tags from the child's DNSKEY RRSIG records (between lifetime > fields and the signer field) and calculate the key tags of the > child's DNSKEY records > > * take the intersection of these three sets; these key tags identify keys > that the parent says can validate the DNSKEY RRset, and that actually do > validate the DNSKEY RRset, and that can be used to validate the DNSKEY > RRset > > * for each DNSKEY in the set, ensure that there is a DS record that > whose digest matches it [ you can skip matching attempts when the key > tags do not match ] > > * using the public keys and signatures you just identified, try to > validate the self-signature on the DNSKEY RRset; if any of the > signatures validates, it's all good! [ again the key tags let you > skip pointless signature validation attempts ] > > There are some extra complications to do with downgrade protection, but > that's the basic idea. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ > women and men working together > ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
