Re: [DNSOP] kskroll-sentinel and unclear results

Warren Kumari <warren@kumari.net> Wed, 30 May 2018 18:24 UTC

Return-Path: <warren@kumari.net>
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 AE2AF129C5D for <dnsop@ietfa.amsl.com>; Wed, 30 May 2018 11:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.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 H0m25KOX5YBr for <dnsop@ietfa.amsl.com>; Wed, 30 May 2018 11:24:17 -0700 (PDT)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 071AF124319 for <dnsop@ietf.org>; Wed, 30 May 2018 11:24:16 -0700 (PDT)
Received: by mail-wm0-x231.google.com with SMTP id a67-v6so49313060wmf.3 for <dnsop@ietf.org>; Wed, 30 May 2018 11:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IlXDao5efCOCmFSV92STGNPhcpkyVjCV6rp0bH+bvsM=; b=lOIpLSNuuiolG40Fhk7oxoXCf4ZhKIZtF19PhzKlBIL2RHbnFPhtzvrY0ACkaEG2K2 FW/RYe0wiwhoQP1hPjQhJxccpY/hLDsy9aTSxg25oepUOf2/e9BTfM7L5NG9GhAhhH6D PMVxCLS1I70Z2BzqJrG51UUDE55AxUK8yllfkJ6NwV8Xh/aB98bg5ouKT+etQUkhHaI4 fv+TJNsH5QyaPb8PNm2YIXJe0/p+7Bfdqt0e8UTn8bf1E+b9cyeJP8P5waY5yU0fsuxV 5HAudN+U86pf5C42y91MsD+ZQOW+jomfYrDorPL5m3vY5Z6uBT8qsBFuImJVa9URU33w XmfQ==
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=IlXDao5efCOCmFSV92STGNPhcpkyVjCV6rp0bH+bvsM=; b=ufB9sNbOEBsV/5wC1f4hFdtIXsBoUbQe8MM9/xnENK6+0zc1KfOGGoqSz56WsyKI4N twtD2JowQjxI1QDoEd448jkPNnmp88zDPfIBhyyCa6mRSbYBZnlVQZSj9Mu54u0ffOmk ajWd0cuCAehdSUgS3H0E5H/alvWBwDt1tly1fB9+lPJGyVgruhcNhB5C8Q4fd/VA7weC I05a+OnKPt8K+M0U56ZU2uwVc13rVh9hwPPJtfBMCAsmInKrv9EZry9jCP9z7oxaa6ed dvxjt2nOcnpwnSMoaQhIKS1sfDTXQS0GcpXoSCqC5tsBobXfkpDl50exDyu0u7iIqSrn sTSQ==
X-Gm-Message-State: ALKqPwdaZB2uIpFq8Aq4KNIgAmDQB7rISSkbNZvyNR6SKBELb4liCshZ S0JAMgYvAFivkYx2nty5wghRExTY9PUk6gr4S60W7rb8
X-Google-Smtp-Source: ADUXVKLpmXMwD71d+ZmTE4JCjmNOgyjUuXLueNZR8mGcIBQQlp5hI50RkgBKvYzDQt4W59+qhmmhcav2gbT+sv4WAHY=
X-Received: by 2002:a1c:4189:: with SMTP id o131-v6mr73163wma.7.1527704655221; Wed, 30 May 2018 11:24:15 -0700 (PDT)
MIME-Version: 1.0
References: <A53AF3DD-205D-4A8D-82DF-3255287FAFB0@vpnc.org> <CAHw9_iLV3R8YxZdN1==FBhekrmSDx+xPm1_Xj8q_1qi0MJ6FGQ@mail.gmail.com> <607759DF-1039-4BA9-A48C-60CF54398BA5@vpnc.org>
In-Reply-To: <607759DF-1039-4BA9-A48C-60CF54398BA5@vpnc.org>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 30 May 2018 14:23:39 -0400
Message-ID: <CAHw9_iKp=XKoU_kp0R-zZ1-jxaJOXLY5teh-MRsPjXOjQqtxKw@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Cc: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zJPQCGblzm-XcUzPGYEHEo5A45c>
Subject: Re: [DNSOP] kskroll-sentinel and unclear results
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, 30 May 2018 18:24:20 -0000

On Thu, May 24, 2018 at 10:51 PM Paul Hoffman <paul.hoffman@vpnc.org> wrote:

> On 23 May 2018, at 11:49, Warren Kumari wrote:

> > On Sun, May 20, 2018 at 10:29 PM Paul Hoffman <paul.hoffman@vpnc.org>
> > wrote:
> >
> >> Greetings. As I re-read the current draft of
> >> draft-ietf-dnsop-kskroll-sentinel, I'm feeling a bit uneasy about the
> >> description of "Vleg" and of what happens when you get a result that
> >> doesn't fit into the query/type table. The draft is fine for when the
> >> results are Vnew, Vold, and nonV, but it gets mushy for other
> >> results.
> >>
> >> It's just a name, but "Vleg" indicates that the resolver is a legacy
> >> validating resolver (that is, doesn't do
> >> draft-ietf-dnsop-kskroll-sentinel). As the document says, that's one
> >> possibility, but you can also get the same set of answers from a set
> >> of
> >> resolvers that validate and support the protocol, but don't all
> >> support
> >> the key whose Key Tag is in the query.
> >>     Similarly, if all the client's resolvers support this mechanism,
> >> but
> >>     some have loaded the key into the trusted key stash and some have
> >>     not, then the result is indeterminate ("Vleg").
> >> The draft also uses "indeterminate" in other places for the result.
> >> Given that, calling it "Vleg" could lead implementers of tests to the
> >> wrong conclusion. Calling it "Vind" would be clearer.
> >>
> >> And this brings up the second point. The earlier sections of the
> >> draft
> >> mix saying that the tests are for "a resolver" and for "a system of
> >> resolvers". Although Section 4 does a good job of discussing the
> >> complications of measuring for a user that has more than one resolver
> >> that have different configurations, earlier sections make the
> >> protocol
> >> sound more definitive than it is.
> >>
> >> If others agree with me that the draft can use better language around
> >> these, I'm happy to offer new proposed text.
> >
> >
> > I for one would like to see proposed text - we can decide from that
> > if it
> > makes things clearer.

> The proposed text is at
>        https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/21
> It's an omnibus change, so you might want to pick up parts, but I think
> as a whole it deals with the above concerns in a consistent fashion.


Thank you, I like most of the changes, but the primary text which addresses
the above question is:
"If the resolvers don't all have the same setup (such as if some validate
but others do not, or if those that validate don't all have the same root
KSKs trusted), the results of the sentinel test described in this document
may be indeterminate.  For example, running the same test twice could get
different results if the different resolvers are queried in a different
order."

I believe that the ordering doesn't matter - it will always converge to the
same answer.
I've got a really long response to this, which shows all of the options in
all the different orders, but my co-authors are in different time-zones,
and want them to sanity check it for me.

Just didn't want you to think we were ignoring you.
W