[DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

Warren Kumari <warren@kumari.net> Mon, 13 January 2020 02:24 UTC

Return-Path: <warren@kumari.net>
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 5CE81120019 for <dnsop@ietfa.amsl.com>; Sun, 12 Jan 2020 18:24:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.20150623.gappssmtp.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 KgyJ27HwCtG1 for <dnsop@ietfa.amsl.com>; Sun, 12 Jan 2020 18:23:59 -0800 (PST)
Received: from mail-qk1-x742.google.com (mail-qk1-x742.google.com [IPv6:2607:f8b0:4864:20::742]) (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 AC7E112001A for <dnsop@ietf.org>; Sun, 12 Jan 2020 18:23:59 -0800 (PST)
Received: by mail-qk1-x742.google.com with SMTP id a203so7261213qkc.3 for <dnsop@ietf.org>; Sun, 12 Jan 2020 18:23:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=mpusZ4DEriy/qbyV5yaLRgeQI/yR4IudWlc37FeITZg=; b=vzTH7tZl7YrBQ8g/lW+oSx4d0CPeng72xPRn/V/dPW2cC7k6iDqCu1BVsWLwBEq498 Sp2qTtHTx6kquZAycZJjjguhTGeGqL6mhtdwy9dP7TEiB1oMkmk8vvwmVLNt8hxIixS3 L2zvLKFQrTE6J16wdj9YEctTvRwYMzAfrt3LLFuo8K9MTFTx7jHxzxfioMW3k8VmdRIB eG8pxL4EYsEN4cS0yx5zzcz6wot0mj7ECPoOEk5GCS1YRLoRCtHuLMbvcfBkdvNgh56S AkA0LNKHF1y11JGnCaelm2TSiI+hofoLpQSS4MizAKX6HQWgejvspZCwWUxDuN50ne+2 mjTw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mpusZ4DEriy/qbyV5yaLRgeQI/yR4IudWlc37FeITZg=; b=m/puJ/fO5SucVMsj3CSQU3u9+jeny9Kw/JZLpyQRj0KnH1+AyzWGq4gphGQZmF9i/r 1ewd1/PCt1YhKTe+COnaUY2r791Ef/pG3Phv02dKWbvR6axhbPHmU1spqyt8Kg2ItoNT 0hfYl8fdoUjDj7upboUkSbBkmUvlD6JCSqOaf+RDMDq5pfVqvjaYeRnK6O0pCPUzFSmw tOd4KWl7/83ra8D2vEuXIqQEq65dWU/pA5GAa2Kaon/hBhTCIWHHHQE6AanuLsP0cwc/ Op7un8y/cPWSIOoM7LS48pApSRmHW/JQZG3m8fOWogB/KDoGqcjoA1KEVStiTJP5TD6V 4oWg==
X-Gm-Message-State: APjAAAV6M2KdR+ZYeyWpf8srkbjTdVMx6O3Wzq/nfiru34hnZ079d6eQ 5lt7UhS+fkjhs7RH1trlWSfz7sMtmRhPUd4VoKDUGA==
X-Google-Smtp-Source: APXvYqxcnJti7QbCY1tLnEhul96eJXzNRcqz+EPLDUBL4r5p2hguhPu7Tla1AhBl4tAJMkL9rS+mmBI9kz3EVEJp2Rs=
X-Received: by 2002:a37:9982:: with SMTP id b124mr13893229qke.245.1578882238452; Sun, 12 Jan 2020 18:23:58 -0800 (PST)
MIME-Version: 1.0
From: Warren Kumari <warren@kumari.net>
Date: Sun, 12 Jan 2020 21:23:22 -0500
Message-ID: <CAHw9_iLFuSbdA2TFS4Qd2dAzDFJyJgfQGY1+T2c2JQZ3WTat_A@mail.gmail.com>
To: draft-ietf-dnsop-multi-provider-dnssec@ietf.org, dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/77fn5uiZ23cKcYb1yLjFTZLw-HI>
Subject: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec
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: Mon, 13 Jan 2020 02:24:01 -0000

Hi there,

Firstly, thank you for a well written and easy to understand document.

I have some comments which I think should be addressed before I start
IETF LC, but they are small enough that if you'd much prefer you can
just address them after during / after LC (if changes are needed), or
during IESG review.
Please let me know LOUDLY which you'd prefer.

1: Section 3: 3. Validating Resolver Behavior
I think it would be very useful to mention that this document doesn't
require any changes to the behavior of validating resolvers
themselves. It might also be worth mentioning somewhere that this is
also largely true for authoritative servers - this isn't really a
protocol change, rather an operational / process set of changes.

2: " Zone owners will want to deploy a DNS service that responds as
   efficiently as possible with validatable answers only, and hence it
   is important that the DNSKEY RRset at each provider is maintained
   with the active ZSKs of all participating providers."
This is somewhat ambiguous - it sounds like the zone owner may want to
deploy a service that is only efficient with verifiable answers (and
might be inefficient with bogus ones :-))

3: A question -- "Authenticated Denial Considerations"
Some CDNs and similar do funny things with e.g CNAMEs, or may do
something like generate ACME records or similar. What happens if
provider A creates e.g _acme-challenge.example.com (or www.example.com
IN 600 CNAME some-long-account-number.cdn.net) and doesn't tell
provider B? I understand that the owner names *should* be consistent,
but I think it is worth adding some text here along the lines of "here
be dragons" or similar...

4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
please either drop this, or add the 2119 / 8174 boilerplate.

Again, I'm willing to start IETF LC, or wait till you've posted a new
version, but please let me know.
W


-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf