Validation succeeds when keys with multiple algorithms present, but not RRSIGs for both

Fri Aug 2 12:25:46 UTC 2013

In message <51FB9C18.23133.401EA34 at tmorizot.sd.is.irs.gov>, "Scott Morizot" wri
tes:
> Hello all,
> 
> I ran into an interesting situation resolving dfas.mil. It appears that 
> they have attempted to roll their ZSKs to algorithm 8 while leaving their 
> KSKs on algorithm 7. Unfortunately, RFC 4035 specifies that if DNSKEYs 
> for multiple algorithms exist in the apex DNSKEY RRset, then an RRSIG for 
> each record set in the zone MUST include at least one RRSIG for each 
> algorithm. (The distinction between KSK and ZSK is an operational 
> convenience and not part of the standard, per se.) The relevant excerpt 
> from Section 2.2 of RFC 4035:
> 
>    There MUST be an RRSIG for each RRset using at least one DNSKEY of
>    each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
>    itself MUST be signed by each algorithm appearing in the DS RRset
>    located at the delegating parent (if any).
> 
> DNSViz and Verisign's DNSSEC debugger correctly report the error.
> 
> http://dnssec-debugger.verisignlabs.com/dfas.mil
> 
> http://dnsviz.net/d/dfas.mil/dnssec/
> 
> However, I discovered when I checked against DNS-OARC ODVR (and my own 
> personal validating recursive nameserver at home) that BIND 9 apparently 
> doesn't correctly enforce that requirement.

Because the requirement is *only* on the signer.  You will note
that the validator is NOT required to check for this as part of the
list of things it is supposed to check for and that is a deliberate
design decision.  If the signer follows this and the timing rules
the zone will not be treated as bogus.  The unbound developers
didn't realise this initially and added unspecified checks to their
validator.

As the zone currently stands a validator that only support alg 8
will treat it as insecure as there is no DS record from alg 8.  A
validator that only supports alg 7 will treat it as secure.  A
validator that supports alg 7 and alg 8 will treat it as secure.

Remember when you introduce a new algorithm you will have cached
records that only have old signature on them which are being returned
to down stream validators and their is no syncronisation of record
expiry.  You may have a old DNSKEY set and new signatures on other
records in the zone or you may have the new DNSKEY set and old
signatures on other records in the zone.  The validator has to work
under both circumstances.

The only RRset that it is possible to perform this consistancy check
on is the DNSKEY RRset itself and both algorithms exist in the RRSIGs.

; <<>> DiG 9.10.0pre-alpha <<>> +dnssec dfas.mil dnskey +multi
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51859
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;dfas.mil.		IN DNSKEY

;; ANSWER SECTION:
dfas.mil.		25300 IN DNSKEY	257 3 7 (
				AwEAAXLZgixJU1KVrdcv+evwuKlDFDmUQR7FsC2zghPU
				mERiPR9wwgpuKdkQ6BQizeObACqfUwepXuBp1b3t0480
				Oyn7OlCaaV+M/O1hH5pkCaRV69iVuWRqPAXfCu6XvHUz
				xL2ugzwr+uYeGrRLfDNsZ1VN/b1zc33c2qdepPbcMDv7
				8ZzXlgy1DJ6DjylOQx7Jm/5uKQiA6sA+W9ViZTHZ9BX9
				9mQcaRqFzY4eVCGid7sgrD71hTxSOnK3b1B1gQEv8CCP
				eZwFsCOG2/9ToTXRxRP1dvIHoWkEEGHy2czb2FbGrfiW
				sRF1uVwoMJRX28D4QndyFy1yWLOMKh0DNyjyePc=
				) ; KSK; alg = NSEC3RSASHA1; key id = 4069
dfas.mil.		25300 IN DNSKEY	256 3 8 (
				AwEAAeIV8hHiYnEiREniwiz5NkAP2yuklG9b0iEBCij0
				F/1Z//Yps0Kk3ss9DprQXqs5MlyCwVJZ1JOIlTe3dlhW
				+fiTBGnSlo/VeBJIfflMAdbzQh7ls9mesdr2kOyjgZzg
				iO8snht0kGYYlr3Qa+4zvSi4p7uJ7oMYEVc7OD13P2PN
				2pM+lwGgB78m9BXLcibw6GBiqVL2M7sY3j0BV1Zbzjd6
				/lEWN1QVktueetc1PfTco9RiJ7vnkw9VpI/FtaKQLDIp
				YWCRPOUoUxLk/ji5r3jez8zQbbe8VxjuH+hyMvb69GMd
				k6Y88vskrCotECqbG/TijhPnDjhfJ0IWY5Kj8Mk=
				) ; ZSK; alg = RSASHA256; key id = 8389
dfas.mil.		25300 IN DNSKEY	256 3 8 (
				AwEAAXzmgOtId7xGSjccxMfW8WlEEJKH7GTnzD58VqhF
				2CJBN0eiyKFxQVwmSdrr9TG/mCVTbAH7RGAP/R3pYxhB
				fBybZp+WwlryBSQIeWpgLFwwv4oLlKxopcpsFcG23Oh5
				BxTuBPW/NCWSu6deGpkA4WQP275Q0gRwjlBKZtD3b8wD
				PsRhL9TsxsYNzLELIW2dnE82YcZB22XVyV0NVbNE1Ks0
				S6oZznxXCp3d2lVw8ImgVm2hCD0c9EZUi7pYf6NedMVH
				mxI5t/JGC22z0Z1/zmQu3z76ZsEhl/uetzSqK9VczmZ3
				JPNNbOtyQHf23lne33mxnZaAuTn81sGLyaVLS6s=
				) ; ZSK; alg = RSASHA256; key id = 1213
dfas.mil.		25300 IN DNSKEY	257 3 7 (
				AwEAAenwNSQi4dIwyzW8Sk27HDklyrQM/2n/TuPRR03k
				ql1Ln4W05Hel9tBiPQ/bmZP5ce11JojB/hekKbKljHA4
				snytiS9Wyd0YHLm7N+kIdDjt95k+aySuJ72YXqgSbexr
				fAOWDtiatyJmd1S/cKvC3S71QIQEUVNS+UsYqAUj6pJ9
				X5kF3L7KS+PoPw0DXBLK6+9KcF4k4RC9siJADVvZy9ay
				fhLq8MxjHW6Qid8nTYn3IGd7nGWfpgrNbugi/BBoYWh1
				+kwtShZcEFx17IkUlUjwuN5nDdvCY6ALofWY9x/sxQdM
				IZi2bprJM71V/UOrsRvRYhwcx+qqYIRLeVa0K08=
				) ; KSK; alg = NSEC3RSASHA1; key id = 32598
dfas.mil.		25300 IN RRSIG DNSKEY 7 2 86400 (
				20130808070034 20130801060034 4069 dfas.mil.
				A2oCGrAHQ+3hlMHqKb5Cst90JyQsJgcWxrbcg4r+rul5
				J2Kg++rIOzMneVI1XDbrke/qZkgkM6+FwGGl8eDpqb5O
				VZdDLtZx4llXeyCKjWKon9gTJu1gdHal3nKZDJsJhfL3
				tqEbPp29XNEyFxb3m+0V6ubYXXh6n/iCSHQfAIVBmWHL
				A0Wp5I9jldzibLK5fqgNq65JTw6/a8WHkOWI/PZMV7g0
				eej3WzUz0C2GC5k6ULgHmSS/wAHHzHz4z0IDGV3vGkJe
				xqHj4FhsgYDNP1cVqw7b4mJyGjKa/samugq3sUnRw0C+
				KRP8o0J0nZos65DmMpJtb5yA9EHwMVLMFg== )
dfas.mil.		25300 IN RRSIG DNSKEY 8 2 86400 (
				20130808070034 20130801060034 8389 dfas.mil.
				EEpPNXelw1QusMw8awFwf7ScAkRNZOEj9RCDk/V9BsTl
				XXvP65lCPD/QEiInJ3I9rglNllzKZxXAWRDjcemwSgkO
				bZdUy/8rsyWm7/KDx7DtzpmS5TS4spdNgmiutH6386YE
				tBf7hjxPR3qE1SqyY+NN4R4QQ3o0M9LGaU4tg+i2laFx
				Gl2K6H4svUbgR8yekVOLqwD9plKGxIpYslMBOK+JW/Zs
				Cae4yY+qwpK6iBZYRdHcvdulEz1ODeRbMsjuec0EOuvw
				DCSY23ltsUR1Hz/D/By/QsL922DUQ3NO2ZD0HcJa1aPp
				lGS/s+q/4yHHd8xT2t7bOse/Ro3CyQkZ5g== )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Aug 02 22:18:34 EST 2013
;; MSG SIZE  rcvd: 1733

> https://www.dns-oarc.net/oarc/services/odvr
> 
> The BIND 9 resolver returns an answer with the AD bit set. Unbound 
> returns SERVFAIL. Secure64 Caches also return SERVFAIL. Those are the 
> only three nameservers I've tested.

Version 1.4.8 onwards should validate the zone.  Earlier versions were
broken.  http://www.unbound.net/documentation/info_algo.html 

> It looks like a validation bug in BIND to me, but I thought I would see 
> what others thought. It's probably a pretty rare situation, since I can't 
> imagine most people who choose to use separate KSKs and ZSKs would try to 
> migrate only their ZSKs to a new algorithm while leaving their KSKs at 
> the old algorithm.

It is not a bug.  Named is working as expected.

> Thanks,
> 
> Scott
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
>  from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org