Re: [DNSOP] Updated KSK Sentinel document

"John Dickinson" <> Fri, 16 February 2018 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97AAA1270FC for <>; Fri, 16 Feb 2018 09:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PFYSQZMfuDYO for <>; Fri, 16 Feb 2018 09:33:06 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 57914126D0C for <>; Fri, 16 Feb 2018 09:33:06 -0800 (PST)
Received: from [2001:b98:204:102:fff1::f145] (port=62431 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <>) id 1emjse-00046M-Dk; Fri, 16 Feb 2018 17:33:04 +0000
From: "John Dickinson" <>
To: dnsop <>
Date: Fri, 16 Feb 2018 17:35:44 +0000
X-Mailer: MailMate (1.10r5443)
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-BlackCat-Spam-Score: 0
Archived-At: <>
Subject: Re: [DNSOP] Updated KSK Sentinel document
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: Fri, 16 Feb 2018 17:33:09 -0000


I like what this draft is trying to do.

I am a bit concerned about adding a invalid RR in to a otherwise 
correctly signed zone. It suspect that there may be a variation in how 
validating resolvers treat authoritative servers that appear to have 
sent bogus data. Some might retry, retry other auth servers, stop using 
that server altogether etc etc…

I suggest that the example A/AAAA RRs on page 4 be written fully 
qualified so there can be no doubt that this draft does not imply new 
special names at the root (which is what I first thought).

In the discussion of Charlie’s resolvers I think “from
    this he knows (see the logic below) that he is using legacy, non-
    validating resolvers.”

should have the “non-“ removed.


On 12 Feb 2018, at 20:28, Warren Kumari wrote:

> <author hat only>
> Hi all,
> Sorry it has taken so long to get a new version of this document
> posted - you deserve better.
> Anyway, we've finally posted an updated version -
> This version includes a (hopefully easily understood) description of
> how this would actually be used, and not just "here's a protocol, k,
> thnx, bye!". I've tried to layout what each party does, and how it all
> fits together - please let me know if it isn't clear. This section is
> towards the top of the document - we will likely make it an Appendix
> before publication.
> I've also updated it to use the kskroll-sentinel-is-ta-<id> format. It
> is easy to change again in the future, but this seemed to be what the
> working group liked. I also updated my demo implementation
> ( to use this naming scheme.
> This version also clarifies that the test is "Is the Key ID a DNSSEC
> root KSK?" Originally my view was that it should be "Is there *any*
> key in the trust store with this keyID?", but after running some
> numbers I decided that there is a significant chance of false
> positives.
> As I mentioned, it took an embarrassingly long time to post the update
> - please let us know if we missed your comments.
> 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
> _______________________________________________
> DNSOP mailing list

John Dickinson

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA