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

Shumon Huque <shuque@gmail.com> Thu, 09 April 2020 14: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 73B223A07AE; Thu, 9 Apr 2020 07:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 Lxgrb4hnwKkn; Thu, 9 Apr 2020 07:38:11 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 861993A07A3; Thu, 9 Apr 2020 07:38:10 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id 103so4288339otv.0; Thu, 09 Apr 2020 07:38:10 -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=c4PQUODQzZQPl/Iho4Mv77q1cbdeyiPUqErp2+zY7dY=; b=a0VhY5+ob/Ji5GTZCW3jiMT869uOYN0tBn3TUwue8wWK+OvGQ2b8AuF5iCQCc4gy+p w0/Cvgc3hvNSDdV0UjeLyRxpNleogspETHrSpmiVZNNdAWME8g4Ht1I5cXWYWXy1Fl1p N/8lL6AEnDmz04Z4OjcDjxyHxGMDQ6HEcqL2aN2aUBCCZv8xVDtKWwBND1oCinBK1ZB2 dnlPU3cJ8jOeAFm2SdsDUAIAcLBk9h8AL7+4XbaWqXyRRBYLBJ2RcFI7788BpSo2i1sE +LpNIvUJCz8+NCMdaUfN4NqfMIg5V7aIWouGPrF68uugJHvBtb+yOCTtlMZEq9rCFobA oFTA==
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=c4PQUODQzZQPl/Iho4Mv77q1cbdeyiPUqErp2+zY7dY=; b=UoKUTsMy24oJJMgL0hRp8iViHvrjYBCdGHONlA6cyVPlEtbB3ZZDYYkxCTRphNgBJt UcaF4/R4X0VFaTAdEXa3/QQHhiI7643gZ8Kg4cDGTbEQ/5rGt6DsErLa7JIjlAJP+m50 GObJi3v8ydXLENAMJQ0GFuEBGd/67x6yVvDT2ARe5oenOJmQz4ATgHVmyc4bKuf+XafO vXPigYkjNnthqGoC9C2pn5RTMQfvl9W1DV6/JZaDKWUm9dIo8rhs4iMntrE34R4ug2TE Cup4sNIoYJ7UUlopQUwqnPrXqgODFXcWHpeMUyirj8dHIIw33Xk3iBqYUiKOpg40cjbJ 6mzQ==
X-Gm-Message-State: AGi0Pua4QeEiRgv2I5i18uzsTf9K7RMCo7YKbZs6ApkwWcZ8a+p8SuWc FWRTgkyC7I7KBysN817NEuKe98gBaEwq4xUXiW4=
X-Google-Smtp-Source: APiQypIl1dwDg9SrDMJ+MGi9827/BoMzGyGxOvQUR6oHvZN6v2W+hFPV3tDy1ideYrcToHfuM01rOwoitfrH8zx2oe0=
X-Received: by 2002:a05:6830:199:: with SMTP id q25mr120346ota.341.1586443089611; Thu, 09 Apr 2020 07:38:09 -0700 (PDT)
MIME-Version: 1.0
References: <158640074339.14937.3827164420742685108@ietfa.amsl.com>
In-Reply-To: <158640074339.14937.3827164420742685108@ietfa.amsl.com>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 09 Apr 2020 10:37:58 -0400
Message-ID: <CAHPuVdXedp-yykvAc+Q6KrggezR6tZvA2LYTd+anc9SFY5BAfg@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
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="000000000000d0111405a2dc9031"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/XawD-7efdXnLBZXmJj3i0Cd4MLw>
Subject: Re: [DNSOP] Roman Danyliw'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: Thu, 09 Apr 2020 14:38:13 -0000

On Wed, Apr 8, 2020 at 10:52 PM Roman Danyliw via Datatracker <
noreply@ietf.org> wrote:

Thank you for your review Roman.

----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for responding to the SECDIR review by Daniel Migault (and
> thanks for
> doing the review Daniel!)  The proposed clarifications would be helpful.
>

Yes, I have several clarifications from that review in the pipeline for the
next
update of the draft.

** Per Section 6.1, “Provider A would generate a new ZSK and communicate
> their
> intent to perform a rollover …”, how is that communication done? Just as
> the
> Security Considerations already talks about API security, is there an
> analogous
> thing to say here in Section 12?
>

That's a good question. We are assuming the zone owner and provider would
either
use a secure out-of-band channel to signal this intent, or the provider API
would have
a relevant function that the zone owner could invoke for this. I'll spell
this out explicitly.

** Section 12.  As key generation is invoked as a step in a number of these
> procedures, provide a pointer good practices for this step would be
> helpful,
> say Section 3.4.4 of RFC6781.
>

We reference 6781 in the earlier section on key rollovers. But sure, I
think it would
be a good idea to re-mention it in Security Considerations for more general
practices
covering security relevant topics.

** Editorial Nits:
> -- A few places.  Typo. s/Authentiated/ Authenticated/g
>
> -- Section 5.1.  Typo. s/prefered/preferred/
>
> -- Section 5.2. Typo. s/Aggresive/Aggressive/
>

Ok.

Shumon Huque