On Fri, Mar 27, 2020 at 6:11 PM Daniel Migault via Datatracker <noreply@xxxxxxxx> 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 ZSKrollovers 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
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
