Re: [DNSOP] Secdir last call review of draft-ietf-dnsop-multi-provider-dnssec-04

[Shumon Huque <[e-mail]>]

On Fri, Mar 27, 2020 at 6:11 PM Daniel Migault via Datatracker <
[e-mail]> wrote:

> Reviewer: Daniel Migault
>

Thank you for your detailed review Daniel.

<mglt>describes</mglt>
>
>    These models do not
>    require any changes to the behavior of validating resolvers, nor do
>    they impose the new key management requirements on authoritative
>    servers not involved in multi signer configurations.
>
> <mglt>
>
> I am reading the last sentence as no changes are expected for servers not
> implementing. Maybe it would be clearer to say that changes are only
> expected
> on server implementing the multi signer described in this document. Of
> course
> this is only a suggestion.
>

Either way works in my opinion, but other reviewers specifically asked us
to point out the "no changes for others" characteristic of these models, so
I'm inclined to leave this as it is.

   The following descriptions consider the case of two DNS providers,
>    but the model is generalizable to any number.


> <mglt>
>
> The only justification for the use of two is that both is once used. I
> think
> this is not really needed with the current text.
>

Yes, I agree. This is probably a remnant of an earlier version of the draft
that specifically mentioned 2 signing providers. The current text in
Section 2 applies generally to any number. I will remove this sentence.

</mglt>
>
> 2.1.1.  Model 1: Common KSK, Unique ZSK per provider
>
> <mglt>
>
> The term Unique may not be appropriated as it could be interpreted as one
> single and not two ZSKs per providers. I think that Unique here means "per
> provider independent ZSK."
>

Yes, that's what it means (unique per provider). I'm thinking about how to
clarify and reword that.

One note also, I am also balanced by considering there is always multiple
> KSKs,
> ZSKs as this could be the case between the key roll overs. On the other
> hand, I
> do not know if it makes the text more complex to read.
>

Sorry, can you elaborate? For model 2, there are always multiple KSKs (at
least 1 per provider). For model 1, there is single KSK (or KSK set, if the
zone owner is rolling or pre-publishing). The section 2 description kind of
glosses over the fact that providers could have multiple keys for the sake
of simplicity, and assumes the reader understands that. The key rollover
section describes one multi-key per provider scenario. I guess one possible
change that might address this is to replace "KSK" with "KSK set" and "ZSK"
with "ZSK set".

I am wondering if it makes sense to also consider this model with one
> provider
> if the content owner wants to keep the ownership/control of the zone.
>

I had considered mentioning that possibility for model 1. (For model 2,
this would just degenerate to a standard configuration, so it isn't worth
describing).

In the early days of the draft, Dave Blacka pointed out to me that model 1
with a single provider is essentially how the DNS root is operated today
(ICANN -> zone owner, Verisign -> signing provider). In the end, I decided
the single signing provider configuration is probably an exceptional case
that we won't see too often in the field. So I left it out, to avoid
overcomplicating the draft. But I'm open to reconsidering. (Or maybe it's
already covered implicitly because it is just the degenerate case where
N=1).

</mglt>
>
>    o  Zone owner holds the KSK, manages the DS record, and is
>       responsible for signing the DNSKEY RRset and distributing the
>       signed DNSKEY RRset to the providers.
>
>    o  Each provider has their own ZSK which is used to sign data.
>
>    o  Providers have an API that owner uses to query the ZSK public key,
>       and insert a combined DNSKEY RRset that includes both ZSKs and the
>       KSK, signed by the KSK.
>
> <mglt>
>
> I believe the text could be clearer on who generates the DNSKEY RRset and
> describe the outputs in an uniform way - that is using RRsets for both
> outputs.
>

Ok.


> The text also seems to indicate the owner directly updates the zone.


The "data content" of the zone, yes.


> While this
> is the resulting outcome, I understood the insertion to the zone as being
> performed by the provider as in some cases a signature with the ZSK may
> also be
> performed.
>

Can you elaborate on what you mean here? The providers always have to
update the zone with new signatures (by their ZSK) for incoming data
changes.

Explanation may actually be more complex then the actual change. The text I
> would propose would be around the lines (assuming I am not missing
> anything):
>
> Providers have an API to enable the owner to retrieve the ZSKs public key
> from
> the providers, generate and return the appropriated DNSKEY and RRSIG
> RRsets.
> The DNSKEY RRset contains the ZSKs of the multiple providers and the KSKs.
> Its associated RRSIG RRset contains the signature of the DNSKEY RRset with
> the
> KSKs.
>

Ok, I'm pondering. Most of this is already covered in different parts of
the draft I believe. And the first sentence of your text above is correct
for model1, but not for model 2.


>
> </mglt>
>    o  Note that even if the contents of the DNSKEY RRset don't change,
>       the Zone owner of course needs to periodically re-sign it as
>       signature expiration approaches.  The provider API is also used to
>       thus periodically redistribute the refreshed DNSKEY RRset.
>
>    o  Key rollovers need coordinated participation of the zone owner to
>       update the DNSKEY RRset (for KSK or ZSK), and the DS RRset (for
>       KSK).
>
> <mglt>
> Unless I am missing something, I believe that the API operating regularly
> could
> proceed to a key roll over in an automated way.


Yes, for the first bullet point above, the action could be fully automated
(and that is what we were expecting would happen).


> The only additional step would
> consists in the publication of the DS RRSet. I am wondering if one is a
> specific key roll over or an emergency key roll over was considered there.
>

Key roll automation is trickier if it involves the DS, although Section 8
could help if specific conditions allow.

We don't specifically call out emergency key rollovers (I'm not sure this
document needs to do that, since it should generally be clear to operators
what needs to be done).

2.1.2.  Model 2: Unique KSK and ZSK per provider
>
>    o  Each provider has their own KSK and ZSK.
>
>    o  Each provider offers an API that the Zone Owner uses to import the
>       ZSK of the other provider into their DNSKEY RRset.
>
> <mglt>
> I think "Zone Owner" was used without capital letter before.
>

Ok, will address.

In this case I believe that the information is the ZSKs public key (as
> opposed
> as the DNSKEY RRset) and that each provider is responsible of publishing
> ZSKs
> of other providers and signing those with their own KSKs and eventually
> their
> own ZSKs. Maybe this could be detailed a bit more.
>

Yes, but I'm not seeing what is not clear in the current text. I will
ponder.

It might be clarifying to specify:
> "Each provider offers an API that the zone owner to import the ZSKs public
> key
> and export the ZSKs public keys of all providers. Each provider will
> generate
> the associated DNSSEY RRset."
>
> What is unclear to me is who generates the DNSKEY RRset. I have the
> impression
> each provider is generating its own DNSKEY.


It depends.

In model 1, is is the zone owner.

In model 2, each provider  updates their DNSKEY RRset with a ZSK (public
key) imported from the other provider(s). Then independently signs the
DNSKEY RRset with their own KSK(s). I will review the current text and see
if I can make this clearer.


> s/both/all/
>

Ok.


> </mglt>
>
>
> 3.  Validating Resolver Behavior
>
[...]

>
>    o  The resolver will not accept this response.  It may still be able
>       to ultimately authenticate the name by querying other nameservers
>       for the zone until it elicits a response from one of provider A's
>       nameservers.  But it has incurred the penalty of additional
>       roundtrips with other nameservers, with the corresponding latency
>       and processing costs.  The exact number of additional roundtrips
>       depends on details of the resolver's nameserver selection
>       algorithm and the number of nameservers configured at provider B.
>
> <mglt>
>
> With the use of geographic authoritative DNS for example, I have the
> impression we
> may also have one provider is only available in from one place and not
> from the
> other thus making the resolution possible probably only possible after
> flushing
> the cache.
>

I assume the other provider(s) would still be reachable, even if they were
geographically or topologically more distant. So if a resolver's nameserver
selection algorithm in this case tends to prefer the more proximal
provider, and none of them return a validatable response, it would
eventually move on to the other providers, or fail because of an aggregate
timeout or exceeding some retry limit. I'm not sure if we need to call out
such special cases explicitly, as we have a more general description that
covers many possible cases.

<mglt>
>
> I have the impression that the resolution does not consider the DS. I think
> that some text needs to be added to mention that all KSK must appropriately
> delegated.
>

Do we need to? In the resolver behavior section, it is implied that
providers have to have a working secure delegation. I suppose we could
mention that, but the section is focussed on what is fundamentally unique
in this configuration.

The DS configuration requirements for each model are described in the model
descriptions earlier in the document.


>
> <mglt>
>
> The Zone Owner deploys a DS RRset at the
>    parent zone that contains multiple DS records, each referring to a
>    distinct provider's KSK.  Hence it does not matter which provider's
>    nameservers the resolver obtains the DNSKEY RRset from, the signed DS
>    record in each model can authenticate the associated KSK.
>
> 4.  Signing Algorithm Considerations
>
>    DNS providers participating in multi-signer models need to use a
>    common DNSSEC signing algorithm.
>
> <mglt>
> I think the text is saying that providers needs to have a common algorithm
> which does not seem correct. The text also only mentions the use of a
> single
> algorithms which I believe is maybe too restrictive. I would propose
> something
> around the following lines:
>

Yeah, good point. We can expand the text to say that each provider needs to
use a common "set" of signing algorithms.

The providers MUST use the same algorithms for signing.
>

As discussed in an earlier thread on dnsop, we decided not to use RFC
2119/8174 keywords. So "must use" or "need to use".

Even though the document is informational, I do not think this prevents
> using
> normative language. Here I would think that a RECOMMENDED might be
> appropriated.
>

See above. But if there is a new consensus on the use of 2119/8174
keywords, we could go there.


>    methods.  This could make caching on the resolver side less efficient
>    and the authoritative servers may observe higher number of queries.
>    This aspect should be considered especially in context of Aggresive
>
> <mglt>
>
> Aggressive maybe?
>

Yes.


>
> The use of mixed method seems to me outside the design of DNSSEC with the
> publication of one zone. The impact on 8198 as well as the additional
> burden
> provided on resolvers seems to me sufficient to at least strongly
> discourage
> the mixed method.
>

I think we do implicitly discourage it, by calling out the deficiencies of
this approach. But yes, we could be more explicit about it.

6.1.  Model 1: Common KSK, Unique ZSK per provider
>
>    o  Key Signing Key Rollover: In this model, the two managed DNS
>       providers share a common KSK which is held by the Zone Owner.
>
> <mglt>
> The text seems confusing as the providers do not actually share the KSK but
> instead publish a common DNSKEY RRsets with the same public part of the
> KSK.
>
> My understanding of sharing a key means that the private part is shared.
> </mglt>
>

Ok. I will clarify.


>
> To
>       initiate the rollover, the Zone Owner generates a new KSK and
>       obtains the DNSKEY RRset of each DNS provider using their
>       respective APIs.  The new KSK is added to each provider's DNSKEY
>       RRset and the RRset is re-signed with both the new and the old
>       KSK.  This new DNSKEY RRset is then transferred to each provider.
>
> <mglt>
>
> At this point the KSK cannot be used so I am wondering if the DS that
> corresponds to the new KSK should not need to be added before the new KSK
> being
> added to the DNSKEY RRset.
>

There are some caveats here. Our text describes the more common Double
Signature KSK rollover model (see RFC 6781 for details). You are describing
the "Double DS KSK Rollover". The prefatory text in Section 6 says the
following:

 "The descriptions in this section assume that KSK rollovers employ the
   commonly used Double Signature KSK Rollover Method, and that ZSK
   rollovers employ the Pre-Publish ZSK Rollover Method, as described in
   detail in [RFC6781].  With minor modifications, they can also be
   easily adapted to other models, such as Double DS KSK Rollover or
   Double Signature ZSK rollover, if desired.

We are trying to avoid repeating lots of text in 6781 and mainly focussing
on the deltas needed to work with multi-signer.

12.  Security Considerations
>
>    The Zone key import APIs required by these models need to be strongly
>    authenticated to prevent tampering of key material by malicious third
>    parties.  Many providers today offer REST/HTTPS APIs that utilize a
>    number of authentication mechanisms (username/password, API keys
>    etc).  If DNS protocol mechanisms like UPDATE are being used for key
>    insertion and deletion, they should similarly be strongly
>    authenticated, e.g. by employing Transaction Signatures (TSIG)
>    [RFC2845].
>
> <mglt>
> I believe that some words should be provided on the security implied by
> the two
> models.  For the two models the providers signs and so is able to modify
> and
> alter the zone. The content is actually under the responsibility of the
> provider
> not the zone owner. In addition, the zone owner has little mean to check
> the
> appropriated content is being delivered.
>
[...]

Yes, it should be fairly obvious to most readers that having 3rd-party DNS
providers sign your zone data means delegating a huge amount of trust to
them. But I agree that this should be explicitly discussed in the Security
Considerations section, and contrasted with the "zone owner operated
signing master + zone transfer approach". I will work on some text for this.

Shumon Huque