Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

[Shumon Huque <[e-mail]>]

On Tue, Jan 21, 2020 at 11:41 AM Matthijs Mekking <[e-mail]>
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.