Reviewer: Daniel Migault
Review result: Has Nits
Hi,
Reviewer: Daniel Migault
Review result: Has Nits
I reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security Area
Directors. Document authors, document editors, and WG chairs should
treat these comments just like any other IETF Last Call comments.
Please find my comments below.
Yours,
Daniel
Multi Signer DNSSEC models
draft-ietf-dnsop-multi-provider-dnssec-04
Abstract
Many enterprises today employ the service of multiple DNS providers
to distribute their authoritative DNS service. Deploying DNSSEC in
such an environment may present some challenges depending on the
configuration and feature set in use. In particular, when each DNS
provider independently signs zone data with their own keys,
additional key management mechanisms are necessitated. This document
presents deployment models that accommodate this scenario and
describe these key management requirements.
<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.
</mglt>
[...]
In the models presented, the function of coordinating the DNSKEY or
DS RRset does not involve the providers communicating directly with
each other. Feedback from several commercial managed DNS providers
indicates that they may be unlikely to directly communicate since
they typically have a contractual relationship only with the zone
owner. However, if the parties involved are agreeable, it may be
possible to devise a protocol mechanism by which the providers
directly communicate to share keys.
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.
</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."
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.
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.
</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.
The text also seems to indicate the owner directly updates the zone. 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.
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.
</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. 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.
The reason I am commenting this aspect is that I see the need of manual
coordination as a strong reason against the mechanism.
</mglt>
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.
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.
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. If that is correct, I am wondering
the impact of having different TTLs. At least, the TTL needs to be known by the
zone owner to regularly retrieve and updates the ZSK public key values. If the
zone owner imposes the TTL value, than it makes this easier. For that reason, I
am wondering if that would not be better to have the owner generating the
NDSKEY RRset.
</mglt>
o DNSKEY RRset is signed independently by each provider using their
own KSK.
o Zone Owner manages the DS RRset that includes both KSKs.
<mglt>
s/Zone Owner/zone owner/
s/both/all/
</mglt>
3. Validating Resolver Behavior
The central requirement for both of the Multiple Signer models
(Section 2.1) is to ensure that the ZSKs from all providers are
present in each provider's apex DNSKEY RRset, and is vouched for by
either the single KSK (in model 1) or each provider's KSK (in model
2.) If this is not done, the following situation can arise (assuming
two providers A and B):
o The validating resolver follows a referral (delegation) to the
zone in question.
o It retrieves the zone's DNSKEY RRset from one of provider A's
nameservers.
o At some point in time, the resolver attempts to resolve a name in
the zone, while the DNSKEY RRset received from provider A is still
viable in its cache.
o It queries one of provider B's nameservers to resolve the name,
and obtains a response that is signed by provider B's ZSK, which
it cannot authenticate because this ZSK is not present in its
cached DNSKEY RRset for the zone that it received from provider A.
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.
</mglt>
o It may also be the case that a resolver is unable to provide an
authenticated response because it gave up after a certain number
of retries or a certain amount of delay. Or that downstream
clients of the resolver that originated the query timed out
waiting for a response.
Hence, it is important that the DNSKEY RRset at each provider is
maintained with the active ZSKs of all participating providers. This
ensures that resolvers can validate a response no matter which
provider's nameservers it came from.
Details of how the DNSKEY RRset itself is validated differs. In
model 1 (Section 2.1.1), one unique KSK managed by the Zone Owner
signs an identical DNSKEY RRset deployed at each provider, and the
signed DS record in the parent zone refers to this KSK. In model 2
(Section 2.1.2), each provider has a distinct KSK and signs the
DNSKEY RRset with it.
<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.
<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:
The providers MUST use the same algorithms for signing.
</mglt>
This is because the current
specifications require that if there are multiple algorithms in the
DNSKEY RRset, then RRsets in the zone need to be signed with at least
one DNSKEY of each algorithm, as described in RFC 4035 [RFC4035],
Section 2.2. If providers employ distinct signing algorithms, then
this requirement cannot be satisfied.
5. Authenticated Denial Considerations
Authentiated denial of existence enables a resolver to validate that
<mglt>
s/Authentiated/Authenticated/
</mglt>
a record does not exist. For this purpose, an authoritative server
presents, in a response to the resolver, NSEC (Section 3.1.3 of
[RFC4035]) or NSEC3 (Section 7.2 of [RFC5155]) records. The NSEC3
method enhances NSEC by providing opt-out for signing insecure
delegations and also adds limited protection against zone enumeration
attacks.
[...]
5.1. Single Method
Usually, the NSEC and NSEC3 methods are used exclusively (i.e. the
methods are not used at the same time by different servers). This
configuration is prefered because the behavior is well-defined and
it's closest to the current operational practice.
<mglt>
s/prefered/preferred/
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.
</mglt>
5.2. Mixing Methods
Compliant resolvers should be able to validate zone data when
different authoritative servers for the same zone respond with
different authentiated
<mglt>
s/authentiated/authenticated/
</mglt>
denial methods because this is normally
observed when NSEC and NSEC3 are being switched or when NSEC3PARAM is
updated.
Resolver software may be however designed to handle a single
transition between two authenticated denial configurations more
optimally than permanent setup with mixed authenticated denial
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?
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.
</mglt>
Use of DNSSEC-Validated Cache [RFC8198].
In case all providers cannot be configured for a matching
authentiated denial, it is advised to find lowest number of possible
configurations possible across all used providers.
Note that NSEC3 configuration on all providers with different
NSEC3PARAM values is considered a mixed setup.
6. Key Rollover Considerations
The Multiple Signer (Section 2.1) models introduce some new
requirements for DNSSEC key rollovers. Since this process
necessarily involves coordinated actions on the part of providers and
the Zone Owner, one reasonable strategy is for the Zone Owner to
initiate key rollover operations.
<mglt>
This assumes the zone owner controls the TTL of the DNSKEY.
</mglt>
But other operationally plausible
models may also suit, such as a DNS provider initiating a key
rollover and signaling their intent to the Zone Owner in some manner.
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.
Huque, et al. Expires September 9, 2020 [Page 7]
Internet-Draft Multi Signer DNSSEC models March 2020
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>
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.
</mglt>
The Zone Owner then updates the DS RRset in the parent zone to
point to the new KSK,
<mglt>
It is not clear what point to the new KSK. Does it means that a new DS RRset
has been added and that old and new KSK co-exist? I think I am reading it as
the DS RRset of the old KSK has been removed. I think clarifying text may be needed.
</mglt>
and after the necessary DS record TTL period
has expired, proceeds with updating the DNSKEY RRSet to remove the
old KSK.
[...]
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.
The fact that TTL are controlled by the provider and not the zone owner keeps
the control of the provider to to TTL s after it is being revoked at least for
cached data.
In the second model, the zone maintainer is given up any control. If it is
choosing to remove a KSK and the provider continue serving the zone, he
is affecting the resolution of its zone at - least until the NS expires.
In the first model the zone owner keeps the control of the KSK which enables to revoke
a provider for any new request. In other words, keep a technical mean to revoke
a provider. This will not work on cached RRSet, which means that if a long TTL
has been provided and cached, this RRset will stay in cache even though the
DNSKEY expires. It is one reason we may recommend the resolver to limit the TTL
of the RRsets to not be larger than those of the DNSKEY RRset. I am wondering
if any indication for KSK TTL could be recommended. At least I would expect to
have TTL shorter than in a non delegated case.
The link between the zone owner and the provider also represent an potential
vector of attack, though limited, but I think that would need more text.
</mglt>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
