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