Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 18:17 UTC

Return-Path: <kaduk@mit.edu>
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 7594A130E09; Wed, 26 Sep 2018 11:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 rIO9LLClOMjE; Wed, 26 Sep 2018 11:16:58 -0700 (PDT)
Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8512C130E07; Wed, 26 Sep 2018 11:16:57 -0700 (PDT)
X-AuditID: 12074422-7bfff70000002980-5b-5babcd16e7fe
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.06.10624.71DCBAB5; Wed, 26 Sep 2018 14:16:55 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w8QIGqrZ005113; Wed, 26 Sep 2018 14:16:53 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w8QIGlhg016062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Sep 2018 14:16:50 -0400
Date: Wed, 26 Sep 2018 13:16:47 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Warren Kumari <warren@kumari.net>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-kskroll-sentinel@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@nlnetlabs.nl>, DNSOP Chairs <dnsop-chairs@ietf.org>, dnsop <dnsop@ietf.org>
Message-ID: <20180926181646.GM24695@kduck.kaduk.org>
References: <153797498435.21672.17709898221650275799.idtracker@ietfa.amsl.com> <CAHw9_i+Dm7VHAi8eJjhDyGacCwxigeEZv8tSiGT+ZrW+vxu+oA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHw9_i+Dm7VHAi8eJjhDyGacCwxigeEZv8tSiGT+ZrW+vxu+oA@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjleLIzCtJLcpLzFFi42IR4hRV1hU/uzraYOsZVYv9/Q8ZLd5sn8Ri cffNZRaLM2d/sFnM+DOR2WJa22Zmi8PHLjM5sHvsnHWX3WPJkp9MHrdv/GH32Nt7ny2AJYrL JiU1J7MstUjfLoEro/HBO/aCd+4V6/asZWlgnG3RxcjJISFgItF0rJ8FxBYSWMwkMfN8dBcj F5C9kVGie+FeRgjnKpPE1u+nWbsYOThYBFQljrfngTSwCahINHRfZgaxRYDCjQv2s4PUMwu8 ZpT4+/czE0hCWCBb4uCdXkYQmxdo24mfLSwQQ6cySpze/Q4qIShxcuYTsDOYBbQkbvx7yQSy jFlAWmL5Pw6QMKdAoMTOiTvBlokKKEvs7TvEPoFRYBaS7llIumchdC9gZF7FKJuSW6Wbm5iZ U5yarFucnJiXl1qka6qXm1mil5pSuokRFOzsLko7GCf+8zrEKMDBqMTDG7F+dbQQa2JZcWXu IUZJDiYlUV6FvUAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIrzrtgPleFMSK6tSi/JhUtIcLEri vBNbFkcLCaQnlqRmp6YWpBbBZGU4OJQkeP3PADUKFqWmp1akZeaUIKSZODhBhvMADa89DTK8 uCAxtzgzHSJ/ilFRSpy3GiQhAJLIKM2D6wUlI4ns/TWvGMWBXhHmDQWp4gEmMrjuV0CDmYAG T+hZATK4JBEhJdXAGL42V7ZscctZIa1+75Pr5FhyTs+otDic/u2W/vvgW7ycGmW3wplT3FPf CbyU/T7puWpo8+5pEksf3LK/tSh7hbLMrDrj6lOefxpUp3JUd8bP0pM3PhwmyTi5MLtUTs6W XXuRmsF7db/wzSdeJCwP+T+PZWJ9Gaty88bzPlw5GaGLJ+0ozjmgxFKckWioxVxUnAgAnUR4 syEDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/9XO5XCz38QHFgN3qvQC_HG4CWGk>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 26 Sep 2018 18:17:02 -0000

On Wed, Sep 26, 2018 at 10:12:08AM -0700, Warren Kumari wrote:
> On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk <kaduk@mit.edu>; wrote:
> 
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-dnsop-kskroll-sentinel-15: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Thanks for preparing this document and mechanism; it is good to have more
> > data about the expected impact of the root KSK roll.  That said, I have two
> > Discuss-worthy points, albeit both fairly minor.
> >
> > The first one may just be something that I missed, but does this document
> > actually say anywhere that there needs to be a real zone with real
> > configured A and/or AAAA records for the query names used for these tests?
> > The Appendix sort-of-mentions it, but I feel like there needs to be a
> > mention in the main body text.
> >
> >
> No hats (OMG, everyone will see I'm going bald...)
> 
> Ok, fair. This was actually a source of confusion when we first started
> discussing the document -- we explained it on-list / at mics / in person,
> but it became so well understood that we didn't notice that it is not
> actually specified in the document. I'll try figure out text.

Thanks.

It eventually became pretty clear to me from things like "return the A or
AAAA response unchanged" that there was supposed to be a valid response
provisioned so that it could be returned, but I don't want to rely on all
readers making the same inference.

> 
> > The other point basically is a procedural one, in that we are in effect
> > claiming a couple of leaf name prefixes in all domains to exhibit "weird
> > and surprising behavior" (that is, for parties unaware of this
> > specification).  We generally try to avoid this sort of namespace
> > squatting, preferring (e.g.) /.well-known for HTTP requests, various
> > underscore-prefixed tricks for the DNS, etc.  I see in the changelog that
> > initial attempts did use an underscore prefix but ran into implementation
> > difficulty, and acknowledge that using a "magic" name is much easier to get
> > deployed than (e.g.) a new RR type.  But I do not want the IESG to
> > implicitly approve a namespace claim like this; it's better to be explicit
> > about it if this is the best way to go.
> >
> 
> 
> Ok, I see your point. We've actually done something similar in RFC8145
> where we "reserved" (caused funny behavior) for _ta-XXXX.example.com, but
> this is subtly different. There was some discussion on this and the fact
> that could cause "unexpected" behavior. Unfortunately underscore labels
> really don't work for us -- for example, Android (and some unix machines)
> will not follow / fetch a link of the form http://_foo.example.com.  The
> labels that we are chose (after a huge amount of discussion) are
> "root-key-sentinel-is-ta-XXXX"
> and "root-key-sentinel-not-ta-XXXX". These labels seem sufficiently long
> and obtuse that we don't expect them to be used for anything else (e.g:
> risk of people happening to choose to name a machine
> root-key-sentinel-is-ta-1234.example.com and then being surprised) is
> vanishingly small.

I agree that it's vanishingly small, and the "magic" behavior is just to
return a SERVFAIL, something that in theory could happen at arbitrary times
anyway, so the practical effect is not something I'm especially concerned
about.  (Hey, I did say it was a procedural point!)

> But, yes, this does let let the camel's nose into the tent - we are
> co-opting some names.
> 
> Do you have any suggested text that you could provide to help us explain
> this?

I didn't have anything in particular in mind when I balloted, no (and in
fact I wasn't entirely sure that any new text would be needed, depending on
how we felt about it).  But you're probably right that we should describe
that this is exceptional behavior of a spec, why the impact is minimal, and
why alternative approaches were not suitable.  Feel free to ping me again
about proposing concrete text ... after the telechat.

-Benjamin

> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Other than my Discuss points, I just have a number of essentially editorial
> > nits.
> >
> > Abstract
> >
> >                                 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.  [...]
> >
> > This wording feels confusing to me; I think what it's trying to say is "the
> > root key(s) that are in use by the resolver" but am having a hard time
> > grouping these words to achieve that meaning.  (Is "trust" really necessary
> > to mention, here?)
> >
> > Section 1
> >
> >                RRSIG RRs contain a Key Tag field whose value is equal to
> >    the Key Tag of the DNSKEY RR that was used to generate the
> >    corresponding signature.
> >
> > nit: Is the RR used to generate the signature, or just the key?
> >
> >    o  Users may wish to ascertain whether their DNS resolution
> >       environment resolvers is ready for an upcoming root KSK rollover.
> >
> > nit: I think there's a singular/plural mismatch or similar here, maybe
> > "environment's resolver"?
> >
> >    o  Researchers want to perform Internet-wide studies about the
> >       proportion of users who will be negatively impacted an upcoming
> >       root KSK rollover.
> >
> > nit: "by an upcoming"
> >
> >    If a browser or operating system is configured with multiple
> >    resolvers, and those resolvers have different properties (for
> >    example, one performs DNSSEC validation and one does not), the
> >    sentinel test described in this document can still be used, but it
> >
> > nit: this usage of "but" feels a bit misplaced to me, as the thing being
> > warned about is more that the test may produce indeterminate or
> > inconsistent results.  Or perhaps that the assumptions it makes may not
> > necessarily hold in the specific environments being described (i.e., "these
> > environments").
> >
> >    makes a number of assumptions about DNS resolution behaviour that may
> >    not necessarily hold in all environments.  If these assumptions do
> >    not hold (such as, for example, requiring the stub resolver to query
> >    the next recursive resolver in the locally configured set upon
> >    receipt of a SERVFAIL response code) then this test may produce
> >    indeterminate or inconsistent results.  In some cases where these
> >    assumptions do not hold, repeating the same test query set may
> >    generate different results.
> >
> > Section 1.1
> >
> > Please use the RFC 8174 boilerplate.
> >
> > Section 3
> >
> > I'll note without further comment that we had a long thread on ietf@
> > relevant to the term "slave resolver".
> >
> > Section 3.1
> >
> >    If the resolver is non-validating, and it has a single forwarder,
> >    then the resolver will presumably mirror the capabilities of the
> >    forwarder target resolver.
> >
> > Perhaps this is just me misreading the previous paragraph's introduction to
> > what is clearly a more widely known term of art, but in "has a single
> > forwarder" is the thing of which there is only one the "one or more other
> > resolvers" that the "forwarder" is relaying queries to?  It's just weird
> > for the word "forwarder" mean a different protocol participant when used as
> > a noun vs. adjective.  Or perhaps this is meant to be possessive; the
> > "forwarder's target resolver"?
> >
> > As noted in the directorate review, "use the CD bit" needs disambiguation.
> >
> > Section 4
> >
> > nit: missing trailing 'r' in the section title
> >
> > Section 4.3
> >
> > Maybe call out that these are the same general categories of query as in
> > Section 3 but the key tag used is different for some queries?
> >
> > It's also a bit weird to use new notation for this section as opposed to
> > consistent notation between the different types of test.
> >
> >
> >
> 
> -- 
> 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