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

Job Snijders <> Tue, 08 May 2018 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1918D120227 for <>; Tue, 8 May 2018 01:49:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.668
X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l9ScCb9SL36L for <>; Tue, 8 May 2018 01:49:08 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 465CA120726 for <>; Tue, 8 May 2018 01:49:08 -0700 (PDT)
Received: by with SMTP id j4so17480830wme.1 for <>; Tue, 08 May 2018 01:49:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=MSc+8Y0/Vo/UcrkdKjevv0ZJ/asHu9K8NAZ9BYYxbkk=; b=Tidxbnu9U/tN8ht/3uq+9sAnxJ0JWcf8dnFVsWyV+Q3JubW7p4lZgcMnocvLutLaIQ 0dTIm5CYHS33Qm9qmZyLp6QRIFplVQ0AfF4tp1rX+6tq7soK2oKCjEZEMpZWAMCukDNg TWyQ2cFVwlweE5l3XWqCxHf7kFL+lAvgeeQQjUvs+IbGSGfq0iVqbJVUvDHKc+ZuQxBN MvOVrKtbXZzPAIxSaot5R+vucKGnhb6tUdXoaAmZN/FRWiL2I4xnCVe7t88cvBnzH1Z3 nvWLi3O4RXcFUUsovmuOAz8HTCwVt3zeoRkMQ8TQGqbxHHrj98PWrz/v4YW3UXFCViv5 i5SQ==
X-Gm-Message-State: ALQs6tBW3r3iCukOWih69NrKnEzlgcGS2sJhtA+fxmUrEyNEiVS2Tj46 zgJcHV2ikTKYoj8JxyIMoXv+kw==
X-Google-Smtp-Source: AB8JxZrXvg39PTwff/1SNkFnXcaUpZpfxYHn18mX947l2Jkb+b7EUm3lndJ7FNbcfWwOWL4KxkLygw==
X-Received: by 2002:a50:ce1b:: with SMTP id y27-v6mr39777718edi.300.1525769346443; Tue, 08 May 2018 01:49:06 -0700 (PDT)
Received: from ( []) by with ESMTPSA id b7-v6sm14447535eda.18.2018. (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 08 May 2018 01:49:05 -0700 (PDT)
Received: from localhost ( [local]) by (OpenSMTPD) with ESMTPA id aa2fddfb; Tue, 8 May 2018 08:49:04 +0000 (UTC)
Date: Tue, 8 May 2018 08:49:04 +0000
From: Job Snijders <>
To: Mark Andrews <>
Cc: Tim Wicinski <>, Suzanne Woolf <>, dnsop <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.5 (2018-04-13)
Archived-At: <>
Subject: Re: [DNSOP] draft-ietf-dnsop-kskroll-sentinel-12
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 May 2018 08:49:10 -0000

On Tue, May 08, 2018 at 11:05:50AM +1000, Mark Andrews wrote:
> >> We have also taken the implementation comments posted to the WG
> >> mailing list and collected them in a new section titled
> >> "Implementation Experience” in the light of Suzanne’s request
> >> 
> >> So we would like to pass this draft back to the WG Chairs at this
> >> point for your review for potential submission as an RFC.
> > 
> > 1/ While this is a step in the right direction, I'm not yet entirely
> > impressed by the 'Implementation Experience' section. Is it somehow
> > hard to write an implementation report that describes which
> > implementations comply with the BCP 14 / RFC 8174 terms used in
> > draft-ietf-dnsop-kskroll-sentinel? Are the authors experiencing some
> > blocker in this regard?
> Is it a implementation report or a compliance report?

Well, the current section on the implementations isn't much of either,
it is very sparse. This working group should try to raise the bar for
RFC publication, not explore what the bare minimum is. 

I've used this example before: what I was hoping for is reports that
allude to the BCP14 terms and implementation's compliance similar to
what is done here:
Overviews like these are easy to consume for humans, and are derived
from extensive tests like the one you showed below.

I'd like to note that describing people's intention to implement in a
section called 'Implementation experience' of course doesn't add much
value. :-)

> To actually do a full compliance report for this draft it would
> require including a complete DNSSEC compliance report and in turn a
> complete STD 13 compliance report to meet this “MUST”.
>    DNSSEC-Validating resolvers that implement this mechanism MUST
>    perform validation of responses in accordance with the DNSSEC
>    response validation specification [RFC4035].
> A exhaustive compliance report would run to a couple of thousand tests
> without doing a DNSSEC compliance report due to the combinatorial
> nature of this draft.
> You would need validate as secure zone, a validate as bogus zone, a
> validate as insecure w/ signatures, a validate as insecure w/o
> signatures.  You then for all of these need zones with and without A
> and AAAA records at the test names where without includes both NODATA
> and NXDOMAIN.  You then need to multiply that by servers configured to
> validate and those configured not to validate.  Then you need to
> multiply this by having the functionality enabled or disabled.  You
> then need to do a test for each of the conditions in the list of
> conditions that must be met for the modified responses to be returned.
> You also need to do that where the label looked up after a CNAME and a
> We skipped some of these tests when we built our system tests by I
> believe we hit enough of them to be happy that the code is operating
> correctly.

Yes, I think you are touching upon the core of the issue. Discussing
_how_ to test a specification is exactly the type of discussion to be
held in this working group.

Its commonly accepted that even seemingly simple specifications may be
stringing together a number of complex features. Extensive testing and
demonstrations of such testing are a necessity to be able to claim
'running code and rough consensus'.

> S:rootkeysentinel:Mon May  7 17:55:35 UTC 2018
> T:rootkeysentinel:1:A
> A:rootkeysentinel:System test rootkeysentinel
> [snip]

Thanks for sharing this!

So, the current status is that there is no longer zero, but now a single
implementation of draft-ietf-dnsop-kskroll-sentinel-12?
I see progress, but not last call material.

Kind regards,