Re: [DNSOP] ALT-TLD and (insecure) delgations.

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 08 February 2017 20:36 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 9B71912941A for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 12:36:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KPBnZ_bWurDP for <dnsop@ietfa.amsl.com>; Wed, 8 Feb 2017 12:36:25 -0800 (PST)
Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (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 027DF1289C4 for <dnsop@ietf.org>; Wed, 8 Feb 2017 12:36:25 -0800 (PST)
Received: by mail-io0-x233.google.com with SMTP id v96so209816ioi.0 for <dnsop@ietf.org>; Wed, 08 Feb 2017 12:36:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1Gtm1SpMjToXW9ZgWPwoQGV5IoMnnufx3HrVsIWkZEc=; b=s0KUqZQilCv8Yf3CnsUz7hyyVablbWaY0bc0jpBXjk3m39d+cxq0odNJHauJCCK3XA pckN0XtRNL9ghFgZQcpzEQ6bFOE/43c51GS+wDmIu5m7qTuooWEAGgyojKcWDUBDr78x OpdpbxD2susiy0dy76O/UVa/MWF4QEBMwlZ6XiVLPYDFLKbfNsKn2knys1QJuPe2uaNk lN7IVvQ9UIR25nQTMM37wyit6gTTAnpEij05ZQ0cxvCqjuDP6UsUF2AS6yprOjcWd8Ha cWLrIfWOXXre1ns0fj6QTlZCrhGfjSYlnpGVBkcP2GBhXral7WxD5rl1CI40HEIJ4QVu y9lA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1Gtm1SpMjToXW9ZgWPwoQGV5IoMnnufx3HrVsIWkZEc=; b=rZDEomZSWLf30BMRQerj4ivz7zybqOpuzsHP+lfgkKQWyg9mPPbrktWW9wrDer5Vgf XSQqKGftqNyyo0KLfaHOyinKSszyVxdOVMWWlAe81HtyMTh4fUUltimjXbN5d6BTnZ0K C59Pj3pRRWiToyS9+z9IrGGHLBoy37GoNJgn2l2RKa+rnyCTyUyGpYUNqrM9BMD+Z1/4 gvUJvUhlotIGfiYG1dy9KZRDg3xFhqOR8MCAZGhA7Wo+scNz3Nu8i1gQNpubW4+URvbM zAwZfjW1XOsHN/3TaeVmDnjh38wEXZ8t07RkZEn0QLhV67iWdFUrgdQ7eE2Lph1Q3l4Q Pg+Q==
X-Gm-Message-State: AMke39mE0dSd6D+FX6kQ3Zre+Xaf2cbQoDl71CuMt1nhxY6WQPoWXTEcekDsX3bcH1YZchWL0ITJbLl7QWo4Aw==
X-Received: by 10.107.16.14 with SMTP id y14mr7236ioi.164.1486586184229; Wed, 08 Feb 2017 12:36:24 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.133.208 with HTTP; Wed, 8 Feb 2017 12:36:23 -0800 (PST)
In-Reply-To: <20170208194208.DB02C635DD72@rock.dv.isc.org>
References: <CAH1iCiqXohb_7LsQ2EMo8ZB-t20mKq_nUDS8vebhtSXoM13DTg@mail.gmail.com> <20170203210922.7286C618213C@rock.dv.isc.org> <CAH1iCipKwcOsMQY3kjvSZ42LMK37GLD6GP2AVtnWK0c83k-RiA@mail.gmail.com> <20170207040552.8BDCC632F192@rock.dv.isc.org> <3581BE55-B178-4298-8EE8-73FD16B4216D@gmail.com> <D4C0D518-A3ED-4555-93DA-2EA12D82A662@fugue.com> <CAHw9_iK7Vt+ZNw8=E-b+w9gGhwB9fZNqHYp2pqKqT__RgcDttQ@mail.gmail.com> <5CA637EE-C0B6-4E5C-A446-A84431176D0C@fugue.com> <20170207205554.B6974633BE40@rock.dv.isc.org> <18F2EB0D-5BD0-4CC5-B02C-2E5EA0B8CC23@fugue.com> <20170207214846.B66EF633C6C5@rock.dv.isc.org> <FB835756-2C46-40A9-88ED-2F8ADF812BA6@fugue.com> <20170208052544.862956356F33@rock.dv.isc.org> <FFAFD844-824C-44EA-A4B1-1AD28B4FE95C@fugue.com> <20170208060208.8C8E1635864D@rock.dv.isc.org> <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com> <20170208194208.DB02C635DD72@rock.dv.isc.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 8 Feb 2017 12:36:23 -0800
Message-ID: <CAH1iCipA5nvWJqjdGUwJeeT_eU8EH8VYJU2hX1hJoiTb617K8Q@mail.gmail.com>
To: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary=001a113fece27069d105480ad1ac
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/weWddrep1qZUutVOigZKPSzgrqU>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>, Ted Lemon <mellon@fugue.com>
Subject: Re: [DNSOP] ALT-TLD and (insecure) delgations.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 08 Feb 2017 20:36:26 -0000

On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews <marka@isc.org> wrote:

>
> In message <E0A42577-0984-4ADD-8658-91413CBE783D@fugue.com>, Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 1:02 AM, Mark Andrews <marka@isc.org> wrote:
> > > Which assumes agggressive negative caching.   I'm going to make a
> > > realistic assumption that it will take 10+ years for there to be
> > > meaningful (>50%) deployment of aggressive negative caching.
> >
> > First of all, this probably isn't true, since most of the caches we care
> > about are run by network operators, who tend to update more frequently
> > for obvious reasons.   But the solution you propose, which causes a
> > SERVFAIL, involves a specially-prepared resolver.   So if you get to
> > _create_ the problem with a specially-prepared resolver, I get to solve
> > it with a differently specially-prepared resolver.   If you want queries
> > to .alt not to leak, you have to preload your cache with a proof of
> > nonexistence for .alt, and you have to keep it up to date.   This is not
> > terribly difficult to arrange.
> >
> > >> Leaking a query to .alt is harmless.
> > >
> > > Is it?  What reports are we going to see over the next 20 year of
> > > DITL data on *.alt.
> >
> > How is that relevant?   Suppose we don't create .alt, and instead people
> > just pick random top-level domains for their experiments, as they do now.
> >   Will the number of bogus queries to the root be greater, or fewer?
> > Furthermore, queries for .alt are legitimate, in just the same way that
> > queries for .com are.   They just have a different answer.
>
> Me, I'm trying to prevent the SERVFAIL issues the IETF has created for
> .onion.  In particular this from RFC7686
>
>    4.  Caching DNS Servers: Caching servers, where not explicitly
>        adapted to interoperate with Tor, SHOULD NOT attempt to look up
>        records for .onion names.  They MUST generate NXDOMAIN for all
>        such queries.
>
> Without .onion being a insecurely delegation this results in SERVFAIL
> or BOGUS being returned for .onion named when validation is performed
> by any validating software that is not RFC7686 aware.
>
>
So, while technically the instruction (SHOULD NOT) applies to full .onion
names,
it is a SHOULD NOT, not a MUST NOT.

Again, technically, the bit of code to do the following, IMHO, nears the
level of "trivial":
- upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
- cache the response, and as appropriate, re-query periodically.
- If a query for <anything>.onion is received, reply with the authenticated
denial of existence from the root (cached in step 2)

I believe this should prevent any SERVFAIL or BOGUS.

(I think this turns on the pedantic reading of "generate".)



> Nameserver vendors have a choice.  Follow RFC7686 and have their
> clients get a answer that they know cannot be validated or ignore
> this clause and pretend that RFC7686 has never been written so that
> their client get a validatable answer.  Should the IETF have put
> Nameserver vendors in this position?
>
> At this stage we have not yet implemented this clause in BIND.  We
> are aware of RFC7686 and at some point someone will complain that
> we don't implement this.  At that point we will point out to them
> that this results in SERVFAIL or bogus being returned.
>
> Note all through the debate about .onion I raise this issue.  Go
> look at the archives.
>
> Now draft-ietf-dnsop-alt-tld-07 has almost identical wording
>
>    4.  Caching DNS servers SHOULD recognize these names as special and
>        SHOULD NOT, by default, attempt to look up NS records for them,
>        or otherwise query authoritative DNS servers in an attempt to
>        resolve these names.  Instead, caching DNS servers SHOULD
>        generate immediate negative responses for all such queries.
>
> This clause results in BOGUS or SERVFAIL being returned to the DNS
> application if there is a validator in the return DNS path between
> the caching DNS server and the application.
>

See above; maybe the text of alt-tld should be less prescriptive, and
instead use aggressive-negative compatible language (including use of
legitimate, signed denial of existence RRsets).

Brian



>
> Mark
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org
>