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

[Frederico A C Neves <[e-mail]>]

Hi Shumon,

On Tue, Jan 21, 2020 at 10:05:56AM -0500, 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 [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.

Actually the algorithm rollover, following the liberal approach, is a
pure double signing process. With TTLs tuned it is during a short
interval but still double signing the zone.

ftp://ftp.registro.br/pub/gts/gts32/01-br-algorithm-rollover.pdf

> 
> 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?

I guess 6840 sec 5.11 already clarifies it. 4035 sec 2.2 is talking
about signers.

Fred

> 
> 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
> >

> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop