Re: [DNSOP] Multi Provider DNSSEC Models

[Shumon Huque <[e-mail]>]

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

>
> On 20 Mar 2018, at 11:50, Shumon Huque <[e-mail]> wrote:
>
> 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
>
>
> 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.
>

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.