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

[Matthijs Mekking <[e-mail]>]

Shumon,


On 1/21/20 4:05 PM, 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] <mailto:[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.

If so, then technically they were not conform the RFC, but but I am not
sure how they executed the algorithm rollover precisely. Particularly,
were there ever two DS records in the root zone with different
algorithms for these zones?

>From what I could find, both rollovers did actually sign with double
algorithms though:

See https://static.ptbl.co/static/attachments/179548/1529933472.pdf:

    Aug 20 .br Algorithm Rollover Begin (all times UTC)at 06:00 Zones
    double signed with old and new algorithm

And on this blog
https://www.sidnlabs.nl/en/news-and-blogs/keep-m-rolling-monitoring-ses-dnssec-algorithm-rollover
it looks like .SE was following the RFC 6781 approach.

Please correct me if I am reading this wrong.


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

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.

Best regards,

Matthijs



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