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

Warren Kumari <warren@kumari.net> Wed, 23 May 2018 18:40 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 BBACC12D574 for <dnsop@ietfa.amsl.com>; Wed, 23 May 2018 11:40:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T_gfV22RA4vu for <dnsop@ietfa.amsl.com>; Wed, 23 May 2018 11:40:19 -0700 (PDT)
Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 7524D129C6E for <dnsop@ietf.org>; Wed, 23 May 2018 11:40:18 -0700 (PDT)
Received: by mail-wr0-x22e.google.com with SMTP id i12-v6so15116708wrc.4 for <dnsop@ietf.org>; Wed, 23 May 2018 11:40:18 -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=fAQDpw1gRjIptpfFwdxyxFEHhk/g0cOXlgkaWGRV6yA=; b=wLBMTVb0YEeYO2uo+1lFnPsyQOroQjO8t2OVu18+e0VINki0X5Q0HdppUzYsgEvYGU 31zrQpADbG46511YC+bplaDq4D+Z7fgwoXPAlly+pCauCzQ0gDPAEfT416eSqxDyL5aP 7ApdY0qrBwrO69gZJNDR+aaQ6pnsv+hTiUuQcSKlRbXiPvi//AoN/l9RfgBkt+9tCNxb nojSSxP+yarYSDnEVXYdEG7KwxZ1G42DukTCBRe0CuVLRQHcBzYKD6ns7hSqD3KB0fRv D/gf7SbW7RS1efJt0r2gaZ94eMe9BULIubm62GxWZuwpw2NsYbljzrHL7VqbjuEI0v9g PrBQ==
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=fAQDpw1gRjIptpfFwdxyxFEHhk/g0cOXlgkaWGRV6yA=; b=bY4U5btcLnjlT1HQUZZ0HiM2j5rxOaRCDwIkN3YFo7Wlgz3Tp3hbexBWiy1kesJ2dN j7zyW4znTRsIhhe4Xt6nHZy/zQ0D4wfuZLjLnMNNMBkOxblM+sLcwDkkjugNmEkIpT5k fi/bEKH6Rfb0GIBWexLboe7jpaieii4DrwlfOVGEgh33ThkLuVgQygeKBk0gnCD0hfwX MfqwXv1A+AfiFIRABFXD1vzAos/hBMOe1AQ2Uy5QiOQB8xxRBXcmZi1FkGAONnzvA6/P RPGFms0wGofHC66REmwNOA7xavy6Zvxg7VkYvvO4WY/2U7H0tAhz6QWLOre5uID6QWOA 0Rjg==
X-Gm-Message-State: ALKqPweXWCk57BAVAq162Wg3ZADN5Mpl+IrvqRt7/QpK0tQAF8T1HN+Z Wp78XIff0w8N/9IbMd3+koqzFJyrPVCtdcp8uZdzufHeO1Q=
X-Google-Smtp-Source: AB8JxZpfMrpRx0JsltOLT3L0gcxvhSrIEIK4/DMGryQx72wuQLMvl2256gBxOTjNraU3PfZcMbd1eV/mx0oAHRKewPQ=
X-Received: by 2002:adf:b685:: with SMTP id j5-v6mr3738715wre.10.1527100816519; Wed, 23 May 2018 11:40:16 -0700 (PDT)
MIME-Version: 1.0
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> <20180517112945.GB91015@vurt.meerval.net> <7DE138EC-283A-45E9-80AD-42B2E8A337E4@bondis.org>
In-Reply-To: <7DE138EC-283A-45E9-80AD-42B2E8A337E4@bondis.org>
From: Warren Kumari <warren@kumari.net>
Date: Wed, 23 May 2018 14:39:40 -0400
Message-ID: <CAHw9_iK4ETO-VKZGsgHLoAyvrx8Nv=GBFamuVv69t=2oTxAjew@mail.gmail.com>
To: =?UTF-8?Q?Jo=C3=A3o_Damas?= <joao@bondis.org>
Cc: Job Snijders <job@ntt.net>, Tim Wicinski <tjw.ietf@gmail.com>, Suzanne Woolf <suzworldwide@gmail.com>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b48c56056ce3ddac"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bXVSvDzuBcLb9smKPrVRNOv9ndo>
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, 23 May 2018 18:40:24 -0000

On Thu, May 17, 2018 at 9:27 AM Joao Damas <joao@bondis.org> wrote:

>
>
> > On 17 May 2018, at 13:29, Job Snijders <job@ntt.net> wrote:
> >
> > On Mon, May 07, 2018 at 07:07:05PM +0000, Job Snijders wrote:
> >> 3/ Section 3 states: "The responses received from queries to resolve
> >> each of these names would allow us to infer a trust key state of the
> >> resolution environment.".
> >> From what I understand, in today's DNS world we can only reasonably
> >> expect to do one query per packet. It is well understood that many
> >> operators use BGP-4 anycasting (ECMP), the likes of dnsdist, and/or
> >> simple UDP loadbalancers. I think it may be good to document that
> >> running 3 queries (in essence 3 independent experiments) may not
> >> generate sufficient data to properly infer the state (or any state) of
> >> the resolution environment. Each query (as part of a single sentinel
> >> data gathering session) may be handled by an entirely different resolver
> >> with different keys, contaminating any lookup in the proposed truth
> >> tables. Section 4 covers a number of cases where the results are
> >> indeterminate. It maybe should be added to Section 4 that the client has
> >> no awareness of how the resolver environment is constructed, and thus
> >> requiring multiple independent queries to infer state has its downsides.
> >
> > Do the authors agree with the above observation?
>
> No, not really, at least in my case. What you are saying is that an
> incoherent system behaves in inconsistent manners (a service exposes itself
> to the outside as a homogeneous system but doesn’t behave that way). In
> that case the problem is not one or more queries, the problem is an
> internally misconfigured system.
> If you are referring to the case when a client has several resolvers that
> I can try, I think what we can do is stress even more is that this measures
> the client’s resolver environment, not aspects of particular resolvers. We
> are after finding out whether a user can get a successful resolution in
> their configure environment.
>
> ​Just so the WG knows, the authors (myself in particular) had some
productive discussions with Job at the RIPE meeting in Marseille.
​
As a reminder, this mechanism is designed to measure the *user* impact of
the KSK roll - this means that querying the first resolver in e.g:
resolve.conf, getting SERVFAIL and then failing over to the second (or
third or n-th) until a response is received is fine, and expected.

The document currently contains:
"This document specifies a mechanism that will allow an end user and third
parties to determine the trusted key state for the root key of the
resolvers that handle that user's DNS queries."
and
"The sentinel test described in this document determines whether a **user's
browser or operating system** looking up the special names that are used in
this protocol would be able to validate using the root KSK indicated by the
special names. The protocol uses the DNS SERVFAIL response code (RCODE 2)
for this purpose because that is the response code that is returned by
resolvers when DNSSEC validation fails. If a browser or operating system
has multiple resolvers configured, and those resolvers have different
properties (for example, one performs DNSSEC validation and one does not),
the sentinel mechanism **might search among the different resolvers**, or
might not, depending on how the browser or operating system is configured.
Note that the sentinel mechanism described here measures a very different
(and likely more useful) metric than RFC8145.  RFC 8145 relies on resolvers
reporting towards the root servers a list of locally cached trust anchors
for the root zone. Those reports can be used to infer how many resolvers
may be impacted by a KSK roll, but not what the user impact of the KSK roll
will be." (emphasis added)
and
"Note that a slew of other issues can also cause SERVFAIL responses, **and
so the sentinel processing may sometimes result in incorrect
conclusions.**" (emphasis added).

An example of a case where an incorrect conclusion could occur is if the
client is using an Anycast recursive resolver (e.g: 8.8.8.8) and some of
the backends of that Anycast network have only the old key, and some have
the new key, and ECMP directs you to different backend. Another exmaple is
if the resolver learns the new key *during* a clients testing. To me these
feel like pathological cases, and are covered by "may sometimes result in
incorrect conclusions".
Does the WG feel that this is sufficient, or would it like additional text?
If so, can you propose some?
W



> Joao
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>


-- 
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