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

Job Snijders <job@ntt.net> Mon, 07 May 2018 19:07 UTC

Return-Path: <job@instituut.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 2B6F812D96A for <dnsop@ietfa.amsl.com>; Mon, 7 May 2018 12:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
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 Mz9bNXBYgsFs for <dnsop@ietfa.amsl.com>; Mon, 7 May 2018 12:07:24 -0700 (PDT)
Received: from mail-wm0-f49.google.com (mail-wm0-f49.google.com [74.125.82.49]) (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 4789712D962 for <dnsop@ietf.org>; Mon, 7 May 2018 12:07:09 -0700 (PDT)
Received: by mail-wm0-f49.google.com with SMTP id w194so15004182wmf.2 for <dnsop@ietf.org>; Mon, 07 May 2018 12:07:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; 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=vvfyyvL/cOAIvawGdV/FECVGyf4DOmIUVQ57P8y5PbI=; b=e16XOZeNjf4RMBgTD97JfmbtAmXQVIEuZ3n87BZD/yBkPWexWvD20Q4alBhFdcOs3E Sh8JOagMhzNqBXr7gWI8dJTC38VCXDmV0ulnoGW4zoYAMXlh4a17slZBAj0hpIaRlzKp Q+jh5AjQYupfEYUHXIdUwQYYhT4e/IOPN9NTMq8FnRE/4Zg586042ii0db6zgFe8wyKe /Deq/N/5oVIbwymYyD/uH9fQw/sBHbgvcxFuL+f9yTzf5mzVpzmF2QWfVR2LfUOPREEs 7VFdVp3cAXwhfV2xXYudtIBpTCUHjYGfvnR6+O7ZU0W11Nswy+R3b8+cPj06zxsULQRu GJOw==
X-Gm-Message-State: ALQs6tBFXGGn/QFUADuLhr5XoJlHbgaUpY/R8QZzp3gYdKn1Tl3rB2L8 SF2Ku6KMOt7cn5XYPRak/ztF2g==
X-Google-Smtp-Source: AB8JxZqpJAyh7XhZbZ6IVKDGws2XgoHT4g7DFqUtLImylXvU7rMPxQmsm2sjps1kGxnwKB8zQBrsoQ==
X-Received: by 2002:a50:ac1a:: with SMTP id v26-v6mr51580492edc.153.1525720027535; Mon, 07 May 2018 12:07:07 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id d4-v6sm12555551edp.11.2018.05.07.12.07.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 07 May 2018 12:07:06 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id db731d62; Mon, 7 May 2018 19:07:05 +0000 (UTC)
Date: Mon, 7 May 2018 19:07:05 +0000
From: Job Snijders <job@ntt.net>
To: Geoff Huston <gih@apnic.net>
Cc: Suzanne Woolf <suzworldwide@gmail.com>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Message-ID: <20180507190705.GP91015@vurt.meerval.net>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5E7C31BE-EA5F-4A68-96FE-975CFAF77E42@apnic.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.5 (2018-04-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/_Xo9zBJsOOLXlJCdSYLyh2wkOmY>
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: Mon, 07 May 2018 19:07:26 -0000

On Thu, May 03, 2018 at 06:15:49PM +1000, Geoff Huston wrote:
> We have submitted -12 of this draft which we believe incorperates the
> substantive review comments made during the WG Last Call period that
> were posted to the WG Mailing List.
> 
> > Editors: Please take “concern about a description of current
> > implementation status” as WGLC input, and consider what you might be
> > able to add to the draft to address it. 
> 
> 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?

2/ Moving the Walkthrough Example to the end of the document as an
appendix has greatly improved the readability of the document.

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.

Kind regards,

Job