Mark, At 2016-11-25 15:45:08 +1100 Mark Andrews <ma...@isc.org> wrote: > > > > Sorry for being stupid and ignorant here, but again, is there an RFC > > which says you need multiple signatures? > > Yes. RFC4035 and RFC6840. Note the words "entire zone". You can't > have two algorithm is use without multiple signatures for each RRset > in the zone. > > 5.11. Mandatory Algorithm Rules > > The last paragraph of Section 2.2 of [RFC4035] includes rules > describing which algorithms must be used to sign a zone. Since these > rules have been confusing, they are restated using different language > here: > > The DS RRset and DNSKEY RRset are used to signal which algorithms > are used to sign a zone. The presence of an algorithm in either a > zone's DS or DNSKEY RRset signals that that algorithm is used to > sign the entire zone. > > A signed zone MUST include a DNSKEY for each algorithm present in > the zone's DS RRset and expected trust anchors for the zone. The > zone MUST also be signed with each algorithm (though not each key) > present in the DNSKEY RRset. It is possible to add algorithms at > the DNSKEY that aren't in the DS record, but not vice versa. If > more than one key of the same algorithm is in the DNSKEY RRset, it > is sufficient to sign each RRset with any subset of these DNSKEYs. > It is acceptable to sign some RRsets with one subset of keys (or > key) and other RRsets with a different subset, so long as at least > one DNSKEY of each algorithm is used to sign each RRset. > Likewise, if there are DS records for multiple keys of the same > algorithm, any subset of those may appear in the DNSKEY RRset. > > This requirement applies to servers, not validators. Validators > SHOULD accept any single valid path. They SHOULD NOT insist that all > algorithms signaled in the DS RRset work, and they MUST NOT insist > that all algorithms signaled in the DNSKEY RRset work. A validator > MAY have a configuration option to perform a signature completeness > test to support troubleshooting.
Thanks Mark! That's very clear. :) > > I understand that you need multiple signatures on the DNSKEY RRset > > itself, but surely you don't actually need to sign the whole zone with > > multiple signatures? Once I am sure that every validator has the DNSKEY > > RRset with the old and the new DNSKEY ZSK, then I should be able to > > choose either ZSK and use that to sign, right? Why is this different in > > an algorithm roll versus a normal roll? > > The aim of the rules are to ensure that if the validator only supports > a single algorithm in the validator that you will have the data > necessary to validate the response if it has cyptographic proof (DS) > that the zone is signed with a algorithm it supports and it has a > chain of trust. Well, presumably those validators will have to treat the zone as insecure once you finish the algorithm roll. But thinking about it more I can see why you need to double-sign to avoid the zone failing validation for those validators during the roll. Thanks again for putting up with me. :) > > > > A possibly more important concern is that the RIPE NCC did an algorithm > > > > roll last year, and discovered that Unbound and Verisign DNS require > > > > that the algorithm used by the DS be used to sign the entire zone - not > > > > just the DNSKEY RRSET: > > > > > > That was always required. > > > > Sorry, I'm confused. So the algorithm used by the DS has to sign the > > whole zone? Does that mean that Unbound and Verisign DNS had correct > > behavior and it is now broken? Does that mean that BIND is broken? > > No. Unbound and Verisign DNS over stepped the mark. There is the > supply side and the consumption side. The rules are for the supply > side only. RIPE NCC failed to follow the supply side rules. > > You can follow all the rules in RFC 4035 and because the DNS is a > loosely coherent system, you can get a DNSKEY RRset and some other > RRset from the same zone (but not instance) where there are not > RRSIGs for one or more of the algorithms in the DNSKEY RRset. As > a zone in only deemed to be signed by a algorithm when it is listed > in the DS RRset (or published trust anchors) this is not (or should > not have been) a issue. It was only when Unbound and Verisign DNS > started enforcing supply side rule in the validator that it became > a issue. Got it. > > So confused... > > > > > > https://labs.ripe.net/Members/anandb/dnssec-algorithm-roll-over > > > > > > > > I think this deserves special merit and probably mention in the draft, > > > > because it means that you have to do both the KSK and ZSK roll > > > > together. The root cause of this is probably considered a bug in the > > > > Unbound and Verisign DNS software and has been fixed... but also > > > > consider that Unbound is a fairly popular DNS software and likely to > > > > have lots of old versions lying around. That means basically that > > > > unless you don't care about breaking a large portion of the Internet we > > > > are stuck with this limitation. :( > > > > > > > > Of course, rolling to a brand new algorithm (post-2015) that arrives in > > > > the future should be fine, since it will only be implemented in newer > > > > versions of the software which support rolling properly. :) > > > > > > I'm not worried about old versions with broken validators. Let > > > them break. When the few reports come in tell them to upgrade to > > > a current version. To work with those old, non RFC compliant, > > > versions you have to publish RRSIGs before you publish DNSKEYs and > > > ISC is not going to hack named to support such behaviour. > > > > Mark, I certainly encourage you to not worry about broken resolvers in > > your own systems. I don't for my own vanity domains. > > > > But surely you can see how this might not be acceptable to other > > people, right? Surely? Like people may actually have reasons why they > > want to make sure their sites are available to as many people as > > possible? Surely? > > For how many years should we continue to pander operators using > broken software that has been fixed by the vendor years ago. As long as those operators have users that we want to be able to connect to us. Probably this will be until DNS moves to JavaScript and we actually send the code to the resolvers that we want them to run. ;) > > > They don't interoperate and should have CVEs listed against those > > > versions. > > > > > > > ---- > > > > > > > > Finally, mostly as a whine, it's a pity that RFC 6975 forbids > > > > authoritative servers from filtering RRSIG. From a client point of > > view > > > > this would have been a real motivator to including this information, > > > > since an authoritative server could provide the best signatures > > > > possible (smallest/fastest/most secure/patent-free/whatever), and ONLY > > > > those signatures. > > > > > > There are good reasons not to filter RRSIGs. If validators want > > > to only use alg A when alg A and alg B are present in the DS records > > > they are free to write a validator that supports that. > > > > Again, I am confused. > > > > If a validator says "I only support algorithm A", then what reason is > > there to send it signatures for algorithm B? > > > > I can't think of a good reason not to filter RRSIGs, although I fully > > admit that my imagination may just not be up to the task. Actually if we added DS and DNSKEY to the filtering rules, then we could perform an algorithm roll without double-signing. :) (Well, except that nobody implements RFC 6975...) Cheers, -- Shane
pgpVY7g74dI15.pgp
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
