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

[Shumon Huque <[e-mail]>]

Hi Matthijs,

Sorry, I did miss your original note on this point. Now that I've seen it,
I'm copying back [e-mail] 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.

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?

Shumon.

On Tue, Jan 21, 2020 at 3:59 AM Matthijs Mekking <[e-mail]>
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 <[e-mail]>
> To: [e-mail]
>
> 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
>