Re: [DNSOP] Multi Provider DNSSEC Models

Olafur Gudmundsson <ogud@ogud.com> Thu, 22 March 2018 02:15 UTC

Return-Path: <ogud@ogud.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F041200B9 for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 19:15:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QO7waPH3tiRD for <dnsop@ietfa.amsl.com>; Wed, 21 Mar 2018 19:15:20 -0700 (PDT)
Received: from smtp85.ord1d.emailsrvr.com (smtp85.ord1d.emailsrvr.com [184.106.54.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73EF3126BF6 for <dnsop@ietf.org>; Wed, 21 Mar 2018 19:15:19 -0700 (PDT)
Received: from smtp3.relay.ord1d.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1d.emailsrvr.com (SMTP Server) with ESMTP id B04B360072; Wed, 21 Mar 2018 22:15:18 -0400 (EDT)
X-Auth-ID: ogud@ogud.com
Received: by smtp3.relay.ord1d.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id EAE3560063; Wed, 21 Mar 2018 22:15:17 -0400 (EDT)
X-Sender-Id: ogud@ogud.com
Received: from dhcp-954c.meeting.ietf.org (dhcp-954c.meeting.ietf.org [31.133.149.76]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:25 (trex/5.7.12); Wed, 21 Mar 2018 22:15:18 -0400
From: Olafur Gudmundsson <ogud@ogud.com>
Message-Id: <9724C1F6-C470-4B4F-AFB3-2085A1B47B26@ogud.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_DE0098A8-2A6F-479D-B9C2-0E6FC5BE0769"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 22 Mar 2018 02:15:43 +0000
In-Reply-To: <CAHPuVdXy+oYgQEUoHoxN7W1BnuCoa+opHbQ9tbLZX2xDj2xoZg@mail.gmail.com>
Cc: Tony Finch <dot@dotat.at>, "dnsop@ietf.org WG" <dnsop@ietf.org>
To: Shumon Huque <shuque@gmail.com>
References: <CAHPuVdVi5C3nyVuG2aiLefN7eFPOx+GnOCxU40iio_Gn0oQ8qA@mail.gmail.com> <DFCE50F5-2385-4512-BF9F-1266C0DA4D6E@dotat.at> <CAHPuVdXy+oYgQEUoHoxN7W1BnuCoa+opHbQ9tbLZX2xDj2xoZg@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/H-xLtLzacatZnIiz3c61n_53sMk>
Subject: Re: [DNSOP] Multi Provider DNSSEC Models
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Mar 2018 02:15:22 -0000

> On Mar 21, 2018, at 8:35 AM, Shumon Huque <shuque@gmail.com>; wrote:
> 
> On Wed, Mar 21, 2018 at 12:38 AM, Tony Finch <dot@dotat.at <mailto:dot@dotat.at>> wrote:
> 
> On 20 Mar 2018, at 11:50, Shumon Huque <shuque@gmail.com <mailto:shuque@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