On 1/27/20 8:34 PM, Shumon Huque wrote: > On Tue, Jan 21, 2020 at 11:41 AM Matthijs Mekking > <matth...@pletterpet.nl <mailto: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.
Not the strongest available path, but all the available paths. > 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. I was part of that discussion advocating against it, but the best I could do I guess is to make it a SHOULD NOT. This means you can go against this recommendation for valid reasons and unbound finds the downgrade protection a valid reason. > 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 acknowledge that the specification is focused on offline signing, but online signers just pretend that they have signed the entire zone. So I don't see any issue with the phrase "sign the entire zone". Moving a signed zone between operators with disjoint algorithms is not much explored yet. The closest to this scenario is perhaps a move between non-cooperating DNS operators described in RFC 6781, Section 4.3.5.2 and it recommends to go insecure for the duration of the change. > 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. "cannot know the intentions" is hitting the nail on the head. The lack of such signalling is why a validator has to make its own decision to be more relaxed or more strict. > 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. Thanks. Best regards, Matthijs > 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
