Shumon,
On 1/21/20 4:05 PM, 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 <mailto: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. If so, then technically they were not conform the RFC, but but I am not sure how they executed the algorithm rollover precisely. Particularly, were there ever two DS records in the root zone with different algorithms for these zones? >From what I could find, both rollovers did actually sign with double algorithms though: See https://static.ptbl.co/static/attachments/179548/1529933472.pdf: Aug 20 .br Algorithm Rollover Begin (all times UTC)at 06:00 Zones double signed with old and new algorithm And on this blog https://www.sidnlabs.nl/en/news-and-blogs/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover it looks like .SE was following the RFC 6781 approach. Please correct me if I am reading this wrong. > 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? Yes, this is exactly the rationale, and it is a valid one. And this is how unbound works, see https://nlnetlabs.nl/documentation/unbound/info-algo/ for more information. Best regards, Matthijs > Shumon. > > On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <matth...@pletterpet.nl > <mailto: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 > <mailto:matth...@pletterpet.nl>> > To: dnsop@ietf.org <mailto: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
