Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)

Shumon Huque <shuque@gmail.com> Fri, 10 April 2020 13:38 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 639AE3A0A74; Fri, 10 Apr 2020 06:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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 2-LO1j92os_c; Fri, 10 Apr 2020 06:38:40 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (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 3BFB83A0A66; Fri, 10 Apr 2020 06:38:39 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id l23so1869098otf.3; Fri, 10 Apr 2020 06:38:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SVQRUuq3TEsmsXqudvlhr85bY0ZN6cFejwWzKrnQxqo=; b=SxiaWfa8qG/LUO9n/2VhuHzP1lXkiVPjrq2NUEV7IpgpsgVGNeVcQZtdKeBnpnNc4j pfDRYHal8WppiqSy94+SF6da7L0JU5JzpJErKCXoQjJjj+2GfMGk+gKJI0rExDtQK/XT zGktm3DxNEz4O+uHJXtb2i0bu/w2EkCdEeJmZDbVmp1bLNPwb00Q1//ptNRF5vNbpEm+ ++q43zceswLbOzpUdxZ8XPziSIUDG+F/+LlT7fW4is8BkrpZTSrm4kXlzOFWCpCNjeQR kd0LwvDNQOgkObI9X3xeSxH2UPxUaWZWI8oVszKpbaxURTn6KfmFR3Et37+SQkTjYS49 fKwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SVQRUuq3TEsmsXqudvlhr85bY0ZN6cFejwWzKrnQxqo=; b=K6DgWm58Z55Ida/YV7Hz/Ldn53N0BtHKNVx2/ESKzetkeyGfN/HaePnE5/mMv38/Sq vMUe9Yre0Y3E3jb8Z8YBAFX9kfad2PCJkmakngNSyz5oGa8cUZ+kIAgGNcVGKZfZE8EH 4h0K9dufK8ob8QJcItJVbSuGjHRUq5qh+HgZP/1ZlQtBh8dAGc18MksbB0o9nc47iCky c0Sb++JzA4eJwkSWWi2eRl/gq2m49g5wrH1kMKtsHti0enzo+0OPVchRlFQuVXXDiSv5 FJ8cl4RHRnQBIziy04j8YjOM5W+huICts9Qo0zapU4Vn+W60sPUtgeyDnkheZaIjMuQi p1gg==
X-Gm-Message-State: AGi0PuaMksx9lzph7fOyC/4Gesgwa6kKSlMjFvhvfaYyNerY2XiDSiob JEUdtoLy8Ma6zWuHQXkEwxz1diIDr/bp0VUYR/4=
X-Google-Smtp-Source: APiQypIbUQ1zYoissv0E+izQxA07EF14Mbr2tUjSLghMHsxp01lh4b5p/+Q67k13PFZ7LCE9B3diCYn/5AtD9/cCKhc=
X-Received: by 2002:a05:6830:199:: with SMTP id q25mr4403164ota.341.1586525918241; Fri, 10 Apr 2020 06:38:38 -0700 (PDT)
MIME-Version: 1.0
References: <158640898724.3293.17093328253615706681@ietfa.amsl.com> <CAHPuVdV8APgYx2PnPE7N1sYCDKd_oETTqHLaBaNvLCGuPzigwQ@mail.gmail.com> <20200409221010.GH88064@kduck.mit.edu>
In-Reply-To: <20200409221010.GH88064@kduck.mit.edu>
From: Shumon Huque <shuque@gmail.com>
Date: Fri, 10 Apr 2020 09:38:27 -0400
Message-ID: <CAHPuVdXBe6Ff_puPvt4iX0sks1+iGpVEPgT0MZ+3yFVWWFayMg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-multi-provider-dnssec@ietf.org, dnsop-chairs <dnsop-chairs@ietf.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>, Benno Overeinder <benno@nlnetlabs.nl>
Content-Type: multipart/alternative; boundary="000000000000c8a82e05a2efd9e3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KD-Oq64qvfIkDWYKI_iB-58RfLI>
Subject: Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-multi-provider-dnssec-04: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 10 Apr 2020 13:38:42 -0000

On Thu, Apr 9, 2020 at 6:10 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> >
> > Sure (the short summary is that the adversary can just trivially
> enumerate
> > the zone by querying the provider that employs NSEC). Will add some text.
>
> Oh!  I was misreading this sentence -- I thought that the loss of
> protection was due to mixing NSEC and NSEC3 and some sort of cross-protocol
> interaction, but of course this is just the inherent property of any use of
> NSEC.  So maybe s/Doing so/Any use of NSEC/?
>

Yup, that's correct. And your rewording makes it clearer. Will update.

> Section 14.1
> > >
> > > RFCs 2136, 5731 don't currently seem to be cited in a manner that
> > > requires a normative reference.
> > >
> > Yes, ok. I will promote those references.
>

It seems it's my turn to misread. I see now that those are currently already
normative references, and the suggested action is to demote those to
informative.

The reason we had made those normative, is that UPDATE and EPP are
feasible key management APIs for these models, although I know of no
managed DNS provider that currently offers those options. So perhaps
your suggestion is fine.

Shumon.