Hi Shumon, On Tue, Jan 21, 2020 at 10:05:56AM -0500, Shumon Huque 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.
Actually the algorithm rollover, following the liberal approach, is a pure double signing process. With TTLs tuned it is during a short interval but still double signing the zone. ftp://ftp.registro.br/pub/gts/gts32/01-br-algorithm-rollover.pdf > > 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? I guess 6840 sec 5.11 already clarifies it. 4035 sec 2.2 is talking about signers. Fred > > 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
