Subject: [DNSOP] Multi Provider DNSSEC Models

From: Shumon Huque <[email-masked]>
Date: Tue, 20 Mar 2018 11:50:36 +0000

Hi folks,

We've posted a new draft on Multi Provider DNSSEC models,
which we're planning to discuss at Thursday's DNSOP session.

https://tools.ietf.org/html/draft-huque-dnsop-multi-provider-dnssec-02

Thanks!
Shumon.

---

From: Tony Finch <[email-masked]>
Date: Wed, 21 Mar 2018 00:38:25 +0000

> On 20 Mar 2018, at 11:50, Shumon Huque <[email-masked]> wrote:
> 

I have read through it, and it looks pretty good, though I think you are burying the lede.

The first time I looked through I missed the clever parts, and thought to myself that half of the models described in section 2 would make people very sad. But section 4 on resolver behaviour explains the cleverness that avoids making people sad (sharing public keys), so I looked through the model descriptions more carefully and saw that they do in fact mention the trick.

To fix this misunderstanding, the introductory paragraphs in section 2.2 need to explain your cleverness a lot more explicitly. eg this sentence: 

A key requirement here is to manage the contents of the DNSKEY and DS RRset in such a way that validating resolvers always have a viable path to authenticate the DNSSEC signature chain no matter which provider they query and obtain responses from.

Yeah, validation has to work, I know, now tell me the clever trick up front otherwise I might not realise there is one!

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Shumon Huque <[email-masked]>
Date: Wed, 21 Mar 2018 08:35:54 +0000

On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch <[email-masked]> wrote:

> The first time I looked through I missed the clever parts, and thought to
> myself that half of the models described in section 2 would make people
> very sad. But section 4 on resolver behaviour explains the cleverness that
> avoids making people sad (sharing public keys), so I looked through the
> model descriptions more carefully and saw that they do in fact mention the
> trick.
>

Thanks for the review.

> To fix this misunderstanding, the introductory paragraphs in section 2.2
> need to explain your cleverness a lot more explicitly. eg this sentence:
>
>
> *   A key requirement here is to manage the contents of the DNSKEY and DS
>    RRset in such a way that validating resolvers always have a viable
>    path to authenticate the DNSSEC signature chain no matter which
>    provider they query and obtain responses from.*
>
>
> Yeah, validation has to work, I know, now tell me the clever trick up
> front otherwise I might not realise there is one!
>

Ok, the missing part of the up-front description is that each provider has
to import the zone signing (public) keys of the other provider(s) into its
DNSKEY RRset. I can add this and elaborate some more.

By the way, I would not characterize this as a "trick", but rather a fairly
obvious key provisioning step that is needed to make the multi-provider
signing configuration work.

But I agree that this might not obvious to everyone if they haven't thought
through the details. Actually, I added the resolver behavior section, after
I needed to explain more clearly how this worked to a colleague.

Shumon.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 22 Mar 2018 02:15:43 +0000

> On Mar 21, 2018, at 8:35 AM, Shumon Huque <[email-masked]> wrote:
> 
> On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On 20 Mar 2018, at 11:50, Shumon Huque <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> https://tools.ietf.org/html/draft-huque-dnsop-multi-provider-dnssec-02 <https://tools.ietf.org/html/draft-huque-dnsop-multi-provider-dnssec-02>
> Ok, the missing part of the up-front description is that each provider has to import the zone signing (public) keys of the other provider(s) into its DNSKEY RRset. I can add this and elaborate some more.
> 
> By the way, I would not characterize this as a "trick", but rather a fairly obvious key provisioning step that is needed to make the multi-provider signing configuration work.
> 
> But I agree that this might not obvious to everyone if they haven't thought through the details. Actually, I added the resolver behavior section, after I needed to explain more clearly how this worked to a colleague.
> 
> Shumon.

I read the document and it is quite good 
I think only Model #1 makes sense, i.e Zone apex  DNSKEY/CDNSKEY/CDS  RRset's are signed by zone publisher but rest signed by operator on the fly. 

The document covers the case that different providers use different signing algorithms BUT does not cover if they use different negative answer approaches, 
no good answer other than say NSEC with “lies”. 

     Olafur

---

From: Paul Wouters <[email-masked]>
Date: Thu, 22 Mar 2018 08:26:48 -0400 (EDT)

> no good answer other than say NSEC with “lies”. 

I think the document describes what I think of as a new and clever type
of deployment. But it reads as some kind of BCP you could read or skip,
mostly based on the title. Maybe change the title to something like

 	Considerations for DNSSEC multi-signer deployments

Paul

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 12:50:08 +0000

Olafur Gudmundsson <[email-masked]> wrote:
>
> I think only Model #1 makes sense, i.e Zone apex DNSKEY/CDNSKEY/CDS
> RRset's are signed by zone publisher but rest signed by operator on the
> fly.

>From the provider point of view, I think there are a couple of models:

(a) provider has KSK and ZSK; zone owner needs to be able to import other
provider public keys into this provider's DNSKEY RRset, and export signed
DNSKEY RRset.

(b) provider only has ZSK; zone owner needs to be able to export public
keys, and import signed DNSKEY RRsets.

Given this, I think a zone owner can implement either model 1 or
model 2 from the draft. Model 3 requires sharing private keys.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Biscay: Variable 3, becoming southwesterly 4 or 5, occasionally 6. Moderate or
rough. Occasional rain. Good occasionally poor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Mar 2018 13:00:29 +0000

> model 2 from the draft. Model 3 requires sharing private keys.

That's correct. Both model 1 and 2 seem quite viable to me. Maybe Olafur can
elaborate on why he feels only model 1 makes sense.

One thing I would like to discuss is whether this document should recommend
just one model to maximise the chances that multiple providers implement a
common interoperable scheme that a zone owner can successfully deploy.
Providers might be persuadable to implement both models, but anything more
than two, I would guess, will not be practical.

Shumon.

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 22 Mar 2018 13:33:35 +0000

> than two, I would guess, will not be practical.
My preference is that the zone owner can say they are in full control of
the zone authority
Second reason is if provider B is signing the DNSKEY for the zone then it
can remove the key for operator A
which is not the intent of the zone owner.

Olafur

---

From: Tony Finch <[email-masked]>
Date: Thu, 22 Mar 2018 13:42:04 +0000

> than two, I would guess, will not be practical.

I think providers need to implement all the functionality I sketched
above. The zone owner might act as provider (a) holding the KSK private
key; or they might outsource it.

The risk the Olafur mentioned of a KSK provider dropping imported DNSKEYs
from other providers is probably a matter for contracts and lawyers :-)
But it sort of illustrates the point that this functionality is really
useful for phased migration from one provider to another without going
insecure.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: South veering west, 5 to 7, increasing gale 8 or severe gale 9 for a
time. Rough or very rough, occasionally high for a time. Squally showers.
Moderate or poor.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 22 Mar 2018 13:53:19 +0000

> key; or they might outsource it.

That would be great, but I think we need to get feedback from the providers
that they are willing to implement both models, and if not, persuade them to
do so, if that's the recommendation in the document.

> from other providers is probably a matter for contracts and lawyers :-)

Yes, that was my answer to Olafur in person (I'm sitting next to him right
now in DOH :-)

> useful for phased migration from one provider to another without going

Yes, indeed.

Shumon.

---

From: Matthijs Mekking <[email-masked]>
Date: Thu, 22 Mar 2018 15:04:40 +0100

I agree, model 1 and model 2 seems doable. Note that RFC 6781 has some 
text for model 2 on rollover when changing DNS operators.

https://tools.ietf.org/html/rfc6781#section-4.3.5

Matthijs

---

From: Yoshiro YONEYA <[email-masked]>
Date: Fri, 30 Mar 2018 14:47:53 +0900

Hi Shumon,

Thank you for starting good document.
I think this document is also useful for DNS provider transfer (or 
Registrar transfer) without causing DNSSEC insecure state.  Good 
thing is that this document doesn't depend on EPP (can be used with 
TLDs who doesn't employing EPP).

-- 
Yoshiro YONEYA <[email-masked]>

---

From: Shumon Huque <[email-masked]>
Date: Fri, 30 Mar 2018 16:45:39 -0400

> TLDs who doesn't employing EPP).

Thanks! Yes, I agree. Although the main goal of the document is
to describe a steady state configuration involving multiple signing
operators, the key management methods described can also aid
non-disruptive transfer of operation from one provider to another. I
already had on my TODO list to eventually add a section on provider
migration, but I haven't gotten there yet.

Regarding EPP, a zone owner deploying one of the multi provider
models may have to use EPP for bootstrapping the DS RRset contents,
if  the zone in question is an SLD and they are under a TLD that uses
or requires it. But as you say, not all TLDs use EPP, and the document
doesn't express a point of view or requirement on this topic.

For the managed DNS providers themselves, we simply say that they
need to provide some sort of API for ZSK or DNSKEY import. In theory
that could be EPP, but more commonly is some sort of REST/Web based
API. It could also be UPDATE I suppose if they supported it.

Shumon.