On Tue, Jan 21, 2020 at 11:41 AM Matthijs Mekking <matth...@pletterpet.nl> wrote:
> Shumon, > On 1/21/20 4:05 PM, Shumon Huque wrote: > > > > This also begs the question: should we (in another document) update RFC > > 4035, Section 2.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. Thanks for that pointer. The downgrade protection rationale is in contradiction with the spec though. Unbound is going significantly beyond the spec, although the stated rationale is to require all algorithm paths to authenticate, rather than the strongest available path. To quote https://tools.ietf.org/html/rfc6840#section-5.11 (last paragraph): 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. Furthermore, the above paragraph appears to me to be at odds with the requirements about signatures being present for every algorithm in the DNSKEY/DS RRsets. Given the above rule for validators (which incidentally precludes downgrade protection), the only requirement for interoperability on the part of authority servers is to ensure that one valid authentication path always exists (and not to require signing by every algorithm present). I'm disregarding for the moment the somewhat outdated wording in the specs about algorithms required to "sign the entire zone" - which doesn't contemplate the existence of online signers, which only generate signatures on demand for queried names. The authority server requirement also causes a problem for the case that Steve Crocker raises, about moving a signed zone from one operator to another, where the operators support disjoint algorithms. I agree in principle, that absent other information, algorithm downgrade protection is probably a good thing. But in the general case, a validator cannot know the intentions of the zone owner's use of multiple algorithms. And the distinct-algorithm + multi-provider DNSSEC case is one where this can pose a deployment problem. In any case, I don't think we can quickly resolve this issue in favor of an approach that works reliably for our draft. So I will take your suggestion and and put in the "must" language about same algorithms. If we encounter real deployments in the field that require a solution to this problem, we can revisit it in a future revision. -- Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
