> On Mar 21, 2018, at 8:35 AM, Shumon Huque <shu...@gmail.com> wrote:
>
> On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch <d...@dotat.at
> <mailto:d...@dotat.at>> wrote:
>
> On 20 Mar 2018, at 11:50, Shumon Huque <shu...@gmail.com
> <mailto:shu...@gmail.com>> 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
>> <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.
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
