Shumon, You're asking the right questions:
This also begs the question: should we (in another document) update RFC 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact it is being ignored? Frankly, I've always been a bit perplexed by this text, since it has no accompanying rationale. The only compelling rationale I see is downgrade protection - to detect that someone hasn't stripped away the signatures of a stronger algorithm and forced a validator to authenticate only the weaker signatures. But that implies that validators have a documented procedure to rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs ECDSAP256SHA256? On the face of it, absent a good counter argument, this does indeed seem like an appropriate time to revise RFC 4035 as you suggest. Strict adherence to the rule would require a somewhat awkward multi-step process for switching from a provider who only supports algorithm x to a provider that supports -- or at least prefers -- algorithm y. The transition would first have to be to a provider that supports both x and y but is willing to use just x. After the transition, the new provider would then introduce algorithm y, and then would eliminate algorithm x. This seems like an unnecessary and lengthy sequence. Thanks, Steve On Tue, Jan 21, 2020 at 10:06 AM Shumon Huque <shu...@gmail.com> wrote: > Hi Matthijs, > > Sorry, I did miss your original note on this point. Now that I've seen it, > I'm copying back dnsop@ietf.org to see if there are other comments on > your proposal. > > When the Algorithm Considerations section was originally written, I > intentionally did not prohibit the use of multiple algorithms across > providers (even though we recommended against it) for a very > pragmatic reason: I was actually working with 2 DNS providers that > supported disjoint algorithms (one RSASHA256 and the other ECDSAP256), and > was seriously contemplating deploying such a multi-signer configuration in > production. It would be a bit strange to deploy a configuration on the one > hand, and at the same time write a document that explicitly forbid that > configuration. > > You mention that authoritative servers cannot simply ignore the rule that > they must sign all RRsets in the zone with every algorithm in the DNSKEY > RRset. However, in practice it is clearly being ignored. Neither .SE or .BR > double signed their zone data during their algorithm rollovers and there > are other cases. > > As it turns out, the provider that only supported RSASHA256 exited the > managed DNS provider business, and the only vendors we are working with > currently all support our preferred algorithm (ECDSAP256) in common. Hence, > I am now open to updating the document to prohibit it. But will such text > cause aggravation for other potential deployers that may run into a similar > situation with other providers, and do we care? > > This also begs the question: should we (in another document) update RFC > 4035, Section 2 (last paragraph) to relax or eliminate the rule, if in fact > it is being ignored? > > Frankly, I've always been a bit perplexed by this text, since it has no > accompanying rationale. The only compelling rationale I see is downgrade > protection - to detect that someone hasn't stripped away the signatures of > a stronger algorithm and forced a validator to authenticate only the weaker > signatures. But that implies that validators have a documented procedure to > rank algorithms, which I haven't yet seen. Is a 3072-bit RSASHA256 key > stronger or weaker than an ECDSAP256SHA256 key for example, or Ed25519 vs > ECDSAP256SHA256? > > Shumon. > > On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <matth...@pletterpet.nl> > wrote: > >> Hi Shumon, >> >> On 1/20/20 9:21 PM, Shumon Huque wrote: >> > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) >> - >> > please either drop this, or add the 2119 / 8174 boilerplate. >> > >> > >> > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords >> > anywhere else in this document. >> >> Did you see my mail related to this? If you are going with the lowercase >> approach, please use the word "must" instead of "should". >> >> Best regards, >> >> Matthijs >> >> >> -------- Forwarded Message -------- >> Subject: Re: [DNSOP] Working Group Last Call for >> draft-ietf-dnsop-multi-provider-dnssec >> Date: Mon, 13 Jan 2020 09:57:50 +0100 >> From: Matthijs Mekking <matth...@pletterpet.nl> >> To: dnsop@ietf.org >> >> Late to the party, I am sorry. >> >> I am positive about this document, and support publication. I do have >> one comment on the document, requesting an update. >> >> In section 4 it is said it is RECOMMENDED that providers use a common >> signing algorithm. I think this is too weak and it must be a MUST. >> >> The reason given for RECOMMENDED is that the "liberal approach" works. >> The liberal approach says that authoritative zones MUST sign RRsets with >> every algorithm in the DNSKEY RRset, but validating resolvers don't have >> to enforce this requirement. However, that does not mean the >> authoritative server can simply ignore this rule. >> >> Also, if two different providers are using different algorithms, that >> means two DS records with different algorithms are distributed to the >> parent. And now the algorithm is signaled in the parent and a validator >> may execute the multiple algorithms protection check, expecting both >> chain of trusts to work. >> >> In other words, please adapt section 4 to be more strict when it comes >> to multiple algorithms. If you agree, I am happy to provide the >> suggested text. >> >> Again my apologies for bringing this up so late. >> >> Best regards, >> >> Matthijs >> > _______________________________________________ > 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
