DS record RRSIG

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

DS record RRSIG

Josh Kuo
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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DS record RRSIG

Ondřej Surý
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ý
[hidden email]

> On 2 Jul 2019, at 19:34, Josh Kuo <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DS record RRSIG

Josh Kuo
Thank you for the clarification.

On Wed, Jul 3, 2019 at 1:49 AM Ondřej Surý <[hidden email]> 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ý
[hidden email]

> On 2 Jul 2019, at 19:34, Josh Kuo <[hidden email]> 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
> [hidden email]
> 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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DS record RRSIG

Tony Finch
In reply to this post by Josh Kuo
Josh Kuo <[hidden email]> 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.finch  <[hidden email]>  http://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users
Reply | Threaded
Open this post in threaded view
|

Re: DS record RRSIG

Josh Kuo
Tony,

Thank you for that detailed explanation. 

On Wed, Jul 3, 2019 at 2:15 AM Tony Finch <[hidden email]> wrote:
Josh Kuo <[hidden email]> 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.finch  <[hidden email]http://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
[hidden email]
https://lists.isc.org/mailman/listinfo/bind-users