Hi Mark, Sorry for the late answer, IETF and some other stuff keeps me busy.
Let’s start with this We did not and do not propose to remove anything from RFC 4035. Currently we are asking for RFC 6840 to be amended RFC 6840 Section 5.11 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. PROPOSED CHANGE This requirement applies to servers, not validators. Validators SHOULD accept any single valid path. They MUST 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. We absolutely do not want to enable lying. We want to enable transfer of domains between to signers using different algorithms. I share your analysis that this is possible today. It violates RFC 4035 section 2.2. It should work given that you use two fairly well supported algorithms and your resolver follows the “SHOULD” in RFC 6840 section 5.11. So the first step is to change 6840 to “MUST”, so that resolvers use any validation path and do not insist on a specific or all algorithms being present. Secondly, problems arise if a resolver only supports one of the algorithms. In that case half of the answers would be considered bogus. We are looking for a way to make this work. I admit, the problem is not trivial, but I have faith in DNSOP! ( Please don’t prove me wrong. Pretty please!) /Ulrich > On 22 Mar 2022, at 00:59, Mark Andrews <ma...@isc.org> wrote: > > Also the whole point of mandatory to implement (which includes business > practices) is to prevent cases like this. > If a business wants to lie to its customers about supporting DNSSEC it should > be taken to court, preferably by > bodies like the ACCC. > > As for migration between providers, provided there is some co-operation, it > is possible to migrate between two providers with non overlapping algorithms. > It does require the signed zone data to be transferred back and forth between > the operators. It does require DNSKEY records to be swapped. > > raw zone + provider B keys -> add A keys and sign by A -> sign by B > preserving A signatures and keys -> transfer to A for serving. > > This works today and requires no DNSSEC protocol changes. It may require > some minor implementation changes. For BIND that would be to stop stripping > out DNSSEC stuff from A at B when inline signing. It could all be done in > single server instances with views. This is conceptually what BIND does when > introducing a new algorithm with incremental signing except for transferring > the new zone back and forth. > >> On 22 Mar 2022, at 06:58, Ben Schwartz <bemasc=40google....@dmarc.ietf.org> >> wrote: >> >> If we assume the existing install base of resolvers isn't going away, then I >> don't see how we could relax the requirement. There are already deployed >> resolvers enforcing it. You would need a "flag day" to deprecate them, >> which could not happen for many years. >> >> This seems a lot harder than just telling your next DNS provider that you >> can't do business with them until they implement another one of the (very >> small number of) widely implemented algorithms. >> >> Of course, I've personally argued for essentially the opposite of this >> proposal [1]. Until DNSSEC has algorithmic agility without sacrificing >> compatibility or security, it's only usable as "extra" security. >> >> [1] >> https://www.ietf.org/archive/id/draft-schwartz-dnsop-dnssec-strict-mode-00.html >> >> On Mon, Mar 21, 2022 at 12:06 PM Ulrich Wisser <ulr...@wisser.se> wrote: >> Hi Ben, >> >> The proposal is not to remove the possibility of double signatures, but to >> relax the requirement so that other use cases become possible. >> >> Our use case is the transition from one dns provider to another without >> going insecure. If both use the same algorithm you can use the multi-signer >> dnssec to do this. But if the signers only support a distinct set of >> algorithms you are out of luck. >> >> As Libor pointed out, there are some implications to validation that must be >> considered. >> >> I would say, there are no obvious or easy solutions. But I think/hope that >> DNSOP will be able to come up with some ideas that we can explore. >> >> >> /Ulrich >> >> >>> On 21 Mar 2022, at 10:32, Ben Schwartz <bem...@google.com> wrote: >>> >>> I'm concerned about this. Concretely, this seems like it would raise a >>> major barrier to rolling out new algorithms. For example, any zone that >>> offers ECDSA and RSA signatures would be insecure for any RSA-only >>> resolvers. It's hard to see how new algorithms could be adopted at scale >>> if this rule were in place. >>> >>> On Sun, Mar 20, 2022 at 4:42 PM libor.peltan >>> <libor.peltan=40nic...@dmarc.ietf.org> wrote: >>> Hi Ulrich, dnsop, >>> thank you for your effort in improving DNS. >>> >>> This is a follow-up to your proposal on easing the requirements by >>> RFC4035, which say, in short, that if there's a DS of an algorithm, >>> there must be a complete DNSKEY set of that algorithm, and if there is a >>> DNSKEY of an algorithm, the whole zone must be signed by RRSIGs of that >>> algorithm. >>> >>> The counter-proposal is to only require at least one valid >>> DS-DNSKEY-RRSIG path to sign each RR in the zone. I understand how this >>> would enable multi-signer setups with the signers supporting different >>> algorithms, which in turn is beneficial to enable smooth transitions >>> between such signers. >>> >>> Let's suppose we go this way. How do we specify the validator behaviour >>> when there are algorithm A and B DNSKEYs, just algorithm B RRSIGs, and >>> the validator only understands algorithm A, but not B? I guess BOGUS >>> will be no longer proper here, we would probably stick at INSECURE. Am I >>> correct? >>> >>> Now a different scenario. There are algorithm A and B DNSKEYs, the whole >>> zone is also signed by both alg A and B RRSIGs, and the validator only >>> understands alg A. Some man-in-the-middle attacker intercepts the >>> answers by fiddling with the records, while removing algorithm A RRSIGs >>> from the packets. The validator ends up with INSECURE and lets the >>> attacker poison some cache... >>> >>> With current DNSSEC requirements, it is enough for security if there is >>> any intersection between the algorithms which the zone is signed by, and >>> the algorithms supported by the validator, respectively. With your >>> proposal, it would be required that the validator supports all the >>> algorithms, which the zone is signed by. >>> >>> I agree that in case the zone is signed by just one algorithm >>> (occasionally being rolled-over to just one different one), these >>> conditions are equivalent. Fortunately, it did not happen yet (or I'm >>> not aware of), that the existence of different validators with distinct >>> sets of supported algorithms forced signers to permanently sign zones >>> with two algorithms in parallel. The question is, if it remains so for >>> the future. I can't imagine what would happen in case of a "post-quantum >>> apocalypse", maybe it wouldn't be a problem, but it might. >>> >>> It would also cause the paradox and indeed creepy security quirk, that >>> if you sign your zone with one more algorithm, which is >>> cryptographically strong but poorly adopted (perhaps experimental), it >>> will result in _less_ security. Hardly anyone does this, but if they do, >>> they will be surprised, I think. >>> >>> Just to be clear, I don't want to fight against your ideas. I'm just >>> pointing at possible problems that could emerge. >>> >>> Thanks, >>> Libor >>> >>> _______________________________________________ >>> 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 > > -- > 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
