Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12

Joe Abley <jabley@hopcount.ca> Wed, 09 May 2018 13:41 UTC

Return-Path: <jabley@hopcount.ca>
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 49942126CB6 for <dnsop@ietfa.amsl.com>; Wed, 9 May 2018 06:41:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 gu_P0nEjU0aj for <dnsop@ietfa.amsl.com>; Wed, 9 May 2018 06:41:07 -0700 (PDT)
Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (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 987B9126BFD for <dnsop@ietf.org>; Wed, 9 May 2018 06:41:07 -0700 (PDT)
Received: by mail-io0-x22b.google.com with SMTP id a10-v6so42699234ioc.9 for <dnsop@ietf.org>; Wed, 09 May 2018 06:41:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=mILfsgV6vAYB8S6Prog/LoOw6ZT3yr2cKg1aOM7W7kA=; b=SHh1P8m+cBMXyzEv8VHwq5cNL/SHldIky2wmhi4MrC9YQz3asGfOPj4gGyoilVSW1E FY70ajjjCqg+phU8x7p9PqR5b3avYTrBVWSZ6JxADJQI6pPDLmygasKbYocmrI9hgON/ C9jlkn7dlt4SOZtJAZvVyor9WfT43mZ6v1vfc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=mILfsgV6vAYB8S6Prog/LoOw6ZT3yr2cKg1aOM7W7kA=; b=Jdt09KpM81F39fwu9VThDe9pyUi4iF4dxVl7bqhTf6RfcukG2jS9oFb7H0IQfNAFYf CysYhM3L90L50iD3fuq6cxGaMsSPZ8JkxyySXSmq2rRhTXzGnl3GvCOHBJj7E2vMGyVE vQJT9KO2owG+BPj0JEFaChquM08qNWsgwkHNSFwwEwG6RGPdFpuNdhepw13iJSPDrfC1 zp+PuImPGY1tntYdvJ/AbXykWoo21wK3QtY5WMwNEXuvMHZ5NvY+QnjBUPh/J6WKB/ij Zd+UzH2hXKEi1VqgZjnyk4M0n/HbDGt2uuQPu2DC0vLJQs5usL0xkLJI0yNMUzt2Wgs2 983Q==
X-Gm-Message-State: ALQs6tCzcRLsitzxvTnmYdv8TjhjXgngzOY2RPVLgpy8vDkjCH363Kkt LxfwX+oGkiENWJYdxMUt3x3ZCaA0YmI=
X-Google-Smtp-Source: AB8JxZrv8RU+gLIa5zSQ8V85iPIv7Bp3iLsrN25HOmojC24C+CUSvlkDpXfpwETIagqdKJf0AZICvQ==
X-Received: by 2002:a6b:ad6a:: with SMTP id w103-v6mr26969175ioe.13.1525873266903; Wed, 09 May 2018 06:41:06 -0700 (PDT)
Received: from node-131fegygkks4lus55z.ipv6.teksavvy.com ([2607:f2c0:101:203:392f:b5a4:b73:9b27]) by smtp.gmail.com with ESMTPSA id 2-v6sm14419736iom.34.2018.05.09.06.41.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 May 2018 06:41:05 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Message-Id: <E1F4450F-1F84-4C2F-9943-DF59515F14A1@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_048C6045-4E98-45B5-81C4-B603DCEB39E8"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 9 May 2018 09:41:04 -0400
In-Reply-To: <d0ed1b41-f803-2cd8-b713-4ecdfe61d492@NLnetLabs.nl>
Cc: dnsop@ietf.org
To: Benno Overeinder <benno@NLnetLabs.nl>
References: <CADyWQ+EE9YCCM03wKvd-HefpoQVqhOfeeLKLV8L2LJj+tqmEzA@mail.gmail.com> <CACWOCC936z-4j8e+d7bvhfr_Mk8tk64tkuiRDTRtrqrBTJBKJw@mail.gmail.com> <CAHw9_iLgTvPHe5jeL-0QZJ4+cxes8bBpCEULuDKThpjXoKzrbA@mail.gmail.com> <20180406134501.GC49550@vurt.meerval.net> <4A943DE7-81BC-41AC-93F7-4EC0975DF6B6@gmail.com> <5E7C31BE-EA5F-4A68-96FE-975CFAF77E42@apnic.net> <20180507190705.GP91015@vurt.meerval.net> <4E18F085-59CE-4DD8-A5CB-44E8F2D246E7@isc.org> <20180508084904.GF91015@vurt.meerval.net> <C8933821-B920-4942-AB67-57F7591B858E@bondis.org> <20180509125618.GT6865@hanna.meerval.net> <d0ed1b41-f803-2cd8-b713-4ecdfe61d492@NLnetLabs.nl>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6gyBi1YnUty7mP9uJSucbbM712Y>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
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: Wed, 09 May 2018 13:41:09 -0000

Hi Benno,

On 9 May 2018, at 09:12, Benno Overeinder <benno@NLnetLabs.nl> wrote:

> There are now 2 implementations of kskroll-sentinel:
> 1) peer-reviewed and merged in the BIND master branch;
> 2) released with Unbound 1.7.1 last week.
> 
> (And the draft mentions the implemention early versions of this
> technique into the Knot resolver.)
> 
> Implementation reports/observations for BIND and Unbound have been sent
> to the mailing list.

That's great.

To the earlier question (the WGLC or WGLCish one) I have sympathy with what Job is saying, but I think we should be pragmatic and not pick on the one DNS extension that is actually seeing coordinated funding, implementation and testing because of problems that have been observed with entirely different extensions whose track record is not so good.

Perhaps an acceptable compromise would be to expand slightly on the implementation reports from -12 (which I tend to agree look a bit like placeholders) and expand them to include details of:

 - specific revisions of code bases, and whether they were released, public and private
 - revisions of code bases (with similar detail) that exhibited interestingly different behaviour from that described in -12

For example, the use of different labels in earlier revisions of the draft seems worth mentioning to the extent that it's possible some code based on those earlier revisions is or has been running, and examples of those labels might well show up in historical or future data sets.

With the observed high level of engagement from three major vendors on this it doesn't seem like fleshing out that section would take very long, and if it helped improve consensus on pushing the doc towards the IESG (which I am in favour of) it might be a good investment in time. I realise it's only a snapshot in time, but really so is a release.

(Draft is good though, and in my opinion it could be written up and sent to the IESG right now. It still has to pass the IESG's scrutiny and an IETF-wide last call though, and I think the suggestions above if followed could only oil the tracks through those processes.)


Joe