Last Call Review of draft-ietf-dnsop-multi-provider-dnssec-04
review-ietf-dnsop-multi-provider-dnssec-04-secdir-lc-migault-2020-03-27-00

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>