[DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 22 March 2017 23:08 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 []) by ietfa.amsl.com (Postfix) with ESMTP id DC43C12709D for <dnsop@ietfa.amsl.com>; Wed, 22 Mar 2017 16:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wZCeLViqqUN8 for <dnsop@ietfa.amsl.com>; Wed, 22 Mar 2017 16:08:26 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 4F31D126C83 for <dnsop@ietf.org>; Wed, 22 Mar 2017 16:08:26 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id f84so72941114ioj.0 for <dnsop@ietf.org>; Wed, 22 Mar 2017 16:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jI1eZVM3cCfKKaKOdRqvSoPlQHrnG7n7xEkZVRBr81Y=; b=bdjjVOaJfg6WQBAbKsDuM50ITh1dl5d6YzUBZIqRCf1NUkK3Z1t93dtuRpSkYvm2Ok M9sGfozLmIdTvr8ayb80Bdb+6mYS8zkNpyRaszDtAHj9ABHhuv+iSGjGviDNLNy5lmxy mpLOHTkIDrg4ffVQ0XwM4QJEYqCv0i2MQIPolERdmynpiRLS7aSFVYGqpcukRVv7OWlK 1538IO4Kb6soLaYbWPkZJl5en0hVBS7GPjjB4jadQ9kIYdG+l1/hWe/0XuF9jX/oCYCq qd7QkDcGvWpsvTGbSqhK3Z3DXHGPQBTZaVCgq94QwdqbthtsALPJTCrU4Jd3s6UY5pYz YISg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jI1eZVM3cCfKKaKOdRqvSoPlQHrnG7n7xEkZVRBr81Y=; b=qMKoWFmZRSdYTE5GIbx0rfmUE9s+KHowv/ecRXVXczjJr+Fg/mDW91MgekCNW5e2CH wCqCC8nPZYJohb6tvSXQEKMWia2RttTGeEkXU6RUrwiSzYegMhp/O8MyYCBW5Hq/gdz6 wafjscScgzoSLO7TceUvptw36Xu/xtn5fH77+Fn3WgH1XEFUikvT8bCGFW+EJClBZUR7 47nql3yJj+NQ7i0uoaf/5WATgHZTOBrrZ7xgS5WOdWyj37rW3kpzxBGQgdwNfibweeXz sjH7u71+IXP8AOQgLUlk+LkP5Q0+B8JO7RO/beVK6/iBQyh/mBY2oin7hRBTpRK3EvAY OWOA==
X-Gm-Message-State: AFeK/H2Wr0Y5tg3cOK1Wj1LIkkSZ06zIvCfwi7A8RKnkofRAGuS70BQPLghcOtz5pOInAWjgJ82AdyS8bjuaUQ==
X-Received: by with SMTP id g140mr37801146ioe.63.1490224105609; Wed, 22 Mar 2017 16:08:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 22 Mar 2017 16:08:25 -0700 (PDT)
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 22 Mar 2017 16:08:25 -0700
Message-ID: <CAH1iCiq6nVGMpv7c1UVc8SurOWLQK1DViETof4W06tRXes=rSA@mail.gmail.com>
To: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary=001a11409824736240054b59d6cf
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KdTYrlcZtMAAc8w3HrEYt0yUKXc>
Subject: [DNSOP] Validating stubs? Was: Re: WG review of draft-ietf-homenet-dot-03
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, 22 Mar 2017 23:08:28 -0000

I was thinking about the DNSSEC validation by stubs, with respect to the
homenet discussion.

And, I was wondering about various trust anchor options (other than ICANN's
current root trust anchor).

It occurred to me, that any non-ICANN trust anchor, would possibly require
5011 key rolls under certain circumstances.

Which begs the question: are validating stub resolvers presumed to be

But, I realize, the issue of 5011 capability also exists for the root trust

So, the dilemma is:

   - Can we assume 5011 stub support regardless?
   - If not, does this make the DNSSEC issue for homenet moot, since the
   root KSK will be rolled in the near future (for some value of "near
   future"), and break stub validation?

On the other hand, if 5011 support by stubs is assumed, there is one
interesting option:

Establish a trust anchor for homenet (whatever name is used), AND publish
the private keys.

This creates the ability to have a master DNS authority server, in any
given homenet instance, sign the data in the homenet zone. The default
software could/would need to ship with the trust anchor, and the private
key. The out-of-the-box behavior would just work, and would verify/validate
properly for validating stubs that ship with the homenet trust anchor.

There would then be the ability for users running their own homenet
networks, to do the equivalent of changing the default password -- they
would be able to do a 5011 key roll, which would cause the default trust
anchor to be replaced with a unique trust anchor for that specific homenet.

It's not part of the homenet standard (yet), but might be worth thinking

Again, the main question is, has an assumption about 5011 support in stubs
been made, and is it a valid assumption?

If not, to re-emphasize, then the "unsigned delegation" thing isn't even
necessary, since the stub resolvers won't be able to validate ANYTHING.