Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-multi-provider-dnssec

Shumon Huque <shuque@gmail.com> Thu, 21 November 2019 02:51 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 45616120911 for <dnsop@ietfa.amsl.com>; Wed, 20 Nov 2019 18:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, 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 UGEX6O4fmyPR for <dnsop@ietfa.amsl.com>; Wed, 20 Nov 2019 18:51:38 -0800 (PST)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 AC931120840 for <dnsop@ietf.org>; Wed, 20 Nov 2019 18:51:38 -0800 (PST)
Received: by mail-ot1-x32b.google.com with SMTP id z25so1605683oti.5 for <dnsop@ietf.org>; Wed, 20 Nov 2019 18:51:38 -0800 (PST)
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=Knvn+Wqii916xyYMzS/Dhx/S2laQCYwRoqvhSvVfMgg=; b=XMo50tkyoO4+Er+dAcOeRBuW5xo0rBAKUF76+TKbX3RuOTlJenqEm2/0O58Jo9d/TF Vn3J019ctGqTnJqRIKKRT+DFqqsPeHjpbNdBDlpI7a9iwLyirvg+YeZKVt5XBvSXw3Ba tj8/7qQ0rqYJ310wrO2XNhpTUR6kJFRo/aXW5cF4Xm3WB9hYKPeX+ZfmV5z0Buyi/Zr8 S6GqLaqx1PuzldRPEHojnFbPBwlLg1jv/66XEh9ve1q4tftdpnDknX/ELkEexa2R76vb VdpIDqo6cBde2R5Y2YHQNkxv4dq8pjd1Fr9gZUlidob++VvkZ+7pnX5GNZU3KuixwjtL glHg==
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=Knvn+Wqii916xyYMzS/Dhx/S2laQCYwRoqvhSvVfMgg=; b=tasgvAF8MqPOAHotF3Cxu8g2snxusNOWXT4kkLC6m27mb19XYqche9EToc506hEK3t UdcV12wdGvv5rnTOKg1OflVW9GsYHKm+K8+/HK6peofua1XfmJuxh6Cjsm8MSPYr8WP6 PG0mdifd29bzSMG5PX7q5A9jwhRs8M/KWW3Qye3NsfZkzFckXv6Ixr6OUNLF2GhKc3FO gmUMwMLi7R+wcc4T3hevSgEK7xwQkHBQnlV+3vKn8PjIQxsC9YC49DROSvq0D65EuFnZ ilKghq0rg8mJBV2xHuKko3UDJubbby8XeGDQBLT5uuxGWXswElkjqTHYYhRCcOJKYBTR oeSw==
X-Gm-Message-State: APjAAAWQnTo+NXvfTQSauwvcYduigvDdeNmzcpC1qWWEvIvmZR+GIww/ qFvgtYxeYmXaNdP3sEo+Iz6isZagpjXRtuERheQ=
X-Google-Smtp-Source: APXvYqxGnxI9hG7Fmmzr9ZVGMlo2sY77TWRNNL9k0YBRvyXcd5iBSQAjvhg3kMPmFG+aXH6lKgOgZzoMiSMsVSCvJxA=
X-Received: by 2002:a9d:6a81:: with SMTP id l1mr4730383otq.369.1574304697933; Wed, 20 Nov 2019 18:51:37 -0800 (PST)
MIME-Version: 1.0
References: <CADyWQ+Gip_1qYv8ZQBBfY3OUFxizOMVMpckQZtZRNu4JJtGnLA@mail.gmail.com> <498723c1-d8a5-2668-966b-b3bb9d7312c5@NLnetLabs.nl> <d6400cf2-90cb-2994-1f0f-e28706d6ea18@time-travellers.org> <20191121012030.GP29946@registro.br>
In-Reply-To: <20191121012030.GP29946@registro.br>
From: Shumon Huque <shuque@gmail.com>
Date: Thu, 21 Nov 2019 10:51:26 +0800
Message-ID: <CAHPuVdVpsw_-xCnk0eViToSP2LbSHPExmJcEy7p61rgWfw5sRA@mail.gmail.com>
To: Frederico A C Neves <fneves@registro.br>
Cc: Shane Kerr <shane@time-travellers.org>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000049e3d90597d26097"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eAib9R7ipYIZyS0EP5PCwTKsTN8>
Subject: Re: [DNSOP] Working Group Last Call for 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: Thu, 21 Nov 2019 02:51:41 -0000

On Thu, Nov 21, 2019 at 9:20 AM Frederico A C Neves <fneves@registro.br>
wrote:

> Shane,
>
> On Wed, Nov 20, 2019 at 04:52:22PM +0100, Shane Kerr wrote:
>
> > One minor thing I noticed while looking through the document. It
> > mentions the Brazilian ccTLD as background why using a liberal rollover
> > is workable:
> >
> >    In fact, testing by the .BR Top Level
> >    domain for their recent algorithm rollover [BR-ROLLOVER],
> >    demonstrates that the liberal approach does in fact work with current
> >    resolvers deployed on the Internet.
> >
> > However, the BR-ROLLOVER reference is to a presentation which discusses
> > the plans to try a liberal rollover in Brazil, but doesn't actually
> > claim that it works. Was there further published research that can
> > support this idea?
>
> There is a presentation I gave at ICANN-63 with the rollover report.
>
>  * ICANN 63 - Oct/2018
>
> https://static.ptbl.co/static/attachments/191746/1540217948.pdf
>
>  Audio (English): starting at 57min50s
>
> http://audio.icann.org/meetings/bcn63/bcn63-OPEN-2018-10-24-T0636-113-en-DNSSEC-Workshop-1-of--3.m3u
>
> This was previously reported at dns-operations,
>
>
> https://lists.dns-oarc.net/pipermail/dns-operations/2018-October/018029.html


Thank you Shane and Frederico,

I had actually meant to include the report produced _after_ the BR rollover
was successful. I've made a note to update the draft to replace the current
earlier reference with this later report from October 2018.


> Besides of this I think there may be already published references of
> this on works of Moritz Muller and Taejoong Chung. They greatly helped
> us with the monitoring of the rollover.
>

If anyone can provide references, we'd be happy to review and consider
including those.

And as a general note on this topic, I want to remind folks that although
the draft says that providers using distinct algorithms can work assuming
validators employ the liberal approach, our strong recommendation is that
the providers all use a common signing algorithm (and common key sizes for
algorithms that support variable key sizes).

Shumon.