Re: [DNSOP] Multi Provider DNSSEC Models

Shumon Huque <shuque@gmail.com> Thu, 22 March 2018 13:53 UTC

Return-Path: <shuque@gmail.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 3EE9912E8DA for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 06:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RIIikZtuXarl for <dnsop@ietfa.amsl.com>; Thu, 22 Mar 2018 06:53:20 -0700 (PDT)
Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5082A12DA07 for <dnsop@ietf.org>; Thu, 22 Mar 2018 06:53:20 -0700 (PDT)
Received: by mail-it0-x22f.google.com with SMTP id k135-v6so11456776ite.2 for <dnsop@ietf.org>; Thu, 22 Mar 2018 06:53:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=meDjv29+sKJTlIFrJhnvtWvNwh4NlXMqcD72NNY/bRI=; b=sSPGPqWEmucncso7HO64059wBJbvTDvz60BX74A1PSe1mN0RIAn97glgTc7LPnclvC Q6g3aDiRkLKTA7RrCJIoAqMka5owXxDhNomoPj2JCAIo8YgrHt4PRfP5f46T67zM+skg vYcrQU/s6dma3UWOyPiAQeBpSISbX64k+uwmt+clewxQGrWSDWk2YP1cjHYVUc6frIsR yVrT3irjPdDXOk4P8PGe/sMMSZJaL7IN5itThL56DMy5Qo66cAD8WJ5gqBEAh9d9LoLh DkdtJDdNfGZ19TJUNzzbFT9AGEmBOBtKMHI1FvYeYNlAZQbaR3UNoSeGs7tCqDm+Lmbx 7aUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=meDjv29+sKJTlIFrJhnvtWvNwh4NlXMqcD72NNY/bRI=; b=VoOkHnJO61Cgv4T+XiWznExCa5yHaKcpeuCilMAD3IvCJXxUIbO29woRsP1Yu1L4lV vrHtaOqj8sigyZxz4caJcxQAKQk66Eb+t6pFDmnrlYokr6jXuCk2Np6TWsIDmtWx9pmt eqACXwkIRkEPYFT1Yp1faecjrInS/wbJjCN/RaY2LQNgilC/CeUUVn55v2dIHRirbOMv oa2ylv1N+ZOENhmmkeHpHbawkQKnya4iDZdilfzttW1+vfC1niIVc3gJ+T27XPz1krFp pI5pZmFOg+MWFWmxx07OezqgJ9+7DBq37MtDUUueRfz9KhxvyzHhdljxJX4uh0oTJ0nU Zgkg==
X-Gm-Message-State: AElRT7EGhuBHbKEmDGneH1Sa0nHnSUgJCmG/+xzCQERN21lFqmnp55f9 WIF5BPQkXFaafkM7/lQU3O/71LCm2gaHVPLtV1nGRYTp
X-Google-Smtp-Source: AG47ELsrip4vZaTdh9J7BPYZZgcwENLut0UCgTgLARAGShF0JldoVcytSTXEOpX1Km9rX/vn7zJfvGy9Wft9KiEFYCk=
X-Received: by 2002:a24:40ca:: with SMTP id n193-v6mr8445457ita.61.1521726799516; Thu, 22 Mar 2018 06:53:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.203.9 with HTTP; Thu, 22 Mar 2018 06:53:19 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.11.1803221335190.4063@grey.csi.cam.ac.uk>
References: <CAHPuVdVi5C3nyVuG2aiLefN7eFPOx+GnOCxU40iio_Gn0oQ8qA@mail.gmail.com> <DFCE50F5-2385-4512-BF9F-1266C0DA4D6E@dotat.at> <CAHPuVdXy+oYgQEUoHoxN7W1BnuCoa+opHbQ9tbLZX2xDj2xoZg@mail.gmail.com> <9724C1F6-C470-4B4F-AFB3-2085A1B47B26@ogud.com> <alpine.DEB.2.11.1803221242040.2781@grey.csi.cam.ac.uk> <CAHPuVdXCWfDP7DwLe84CArfMeqE=b9yQqYJns92km6RWs8ntjg@mail.gmail.com> <alpine.DEB.2.11.1803221335190.4063@grey.csi.cam.ac.uk>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 22 Mar 2018 13:53:19 +0000
Message-ID: <CAHPuVdWx7X04jzz+F-iXAdsLXNAUrZfCa3eocn_YGyGCFRMfhg@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000054ad20056800a164"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Bf5t1exgyJTauIOJKfTEfZ3sTL4>
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 13:53:25 -0000

On Thu, Mar 22, 2018 at 1:42 PM, Tony Finch <dot@dotat.at> wrote:

> Shumon Huque <shuque@gmail.com> wrote:
> > On Thu, Mar 22, 2018 at 12:50 PM, Tony Finch <dot@dotat.at> wrote:
> > >
> > > 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.
> >
> > 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.
>
> 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.
>

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.

>
> The risk the Olafur mentioned of a KSK provider dropping imported DNSKEYs
> 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 :-)


> But it sort of illustrates the point that this functionality is really
> useful for phased migration from one provider to another without going
> insecure.
>

Yes, indeed.

Shumon.