Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis

Joe Abley <jabley@hopcount.ca> Fri, 06 July 2018 04:15 UTC

Return-Path: <jabley@hopcount.ca>
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 2DF46130E8D for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 21:15:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 3_J0NsPVaSyI for <dnsop@ietfa.amsl.com>; Thu, 5 Jul 2018 21:15:29 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 C4448130E85 for <dnsop@ietf.org>; Thu, 5 Jul 2018 21:15:28 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id a4-v6so8681510lff.5 for <dnsop@ietf.org>; Thu, 05 Jul 2018 21:15:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=hhJjpM9ESCda0JBDtOdolFynJiioSKbYtKYSyQoEp+s=; b=oCmyzzJq53cXsmRgBU/2fyJ6uGE77PwLBS/esdKR6E5Zx1qq64Q8E/s0ft98n81w9G NHp0ZGlqIAaoVN9e6zB6M0Mpj8ZpHXgbRumhRq+4XcKjRNBRdgwoQ7FYu+4IGJJuXGuz 1HKTVcIUPL0Bl7/z3F7eGtzmJeYIVwQpVbtTU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=hhJjpM9ESCda0JBDtOdolFynJiioSKbYtKYSyQoEp+s=; b=WcLhnX/Rwn8A1IYkgJ/cfsAqfpXHFDd1it2I33gFqIHyUlMbYCnINA7npq5GwWy3up G5lVypEVCrNLBEiwwUST9SQxHrAeDDsl/7Eo0a+8eU34pbx4rPC8ihu35Rcik+UnTzA6 Ib2eBfQDUX53yqMe8MasgXldHbFBFoLEup/KEBlqIuOJa5Y3NfMl+pIM9tXH5jpefL/C QDg0vTCtjiCIiHkUY0Rwq6VQIooj1xy17K/veoVKlJFaNzEWbmGJtPsmpc0Yu3jO8pXh Xr7FbUSIV3ftY+gsY/Le/lp/HX5/EaFdVb/fejKiVc+EMysTan8mhQMqXjZyu4Kgna7i z3Rw==
X-Gm-Message-State: APt69E1NUuAwG/uU/njqvBv9AzZKNaReGo2409k5aMrsUe+ttvKQE692 GsIMwPMMaHY3oyPPjOyVYeBlGtAftWGLdtEdiEoEEg==
X-Google-Smtp-Source: AAOMgpdumbVdCiuXojRW2xzA6RcuQSXyw0mgnYjaK56do1NaQZ1GeD9H23TVVCXdNynepwaGCA3EwHpFt06bJNps3RE=
X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr5885465lfg.83.1530850526673; Thu, 05 Jul 2018 21:15:26 -0700 (PDT)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Thu, 5 Jul 2018 21:15:25 -0700
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
References: <17A1E6A9-E43F-41AB-B24D-4B29F17FCC07@gmail.com> <CAAiTEH-7bqUZJZbfPSP+2+r6fswixKsFdaNeMLzEQd6YfHpCsw@mail.gmail.com> <4B65C153-BF80-4266-A800-6B6DD6E1C6D6@hopcount.ca> <CAKW6Ri7sxmosXq+m8iCmQwLXTvB8cgobOKcxsbB5r7P2_jgcsw@mail.gmail.com> <CAKr6gn0eo=kad+uG4P_he=61=-4rZYA8oSGyUbRaKqJnQsY-BA@mail.gmail.com>
In-Reply-To: <CAKr6gn0eo=kad+uG4P_he=61=-4rZYA8oSGyUbRaKqJnQsY-BA@mail.gmail.com>
Date: Thu, 5 Jul 2018 21:15:25 -0700
Message-ID: <CAJhMdTNho0xcMOQ4U=P=HCbe11dnh4+=eEdvMQw0dM4vhN95AA@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
Cc: Dick Franks <rwfranks@acm.org>, IETF DNSOP WG <dnsop@ietf.org>, Matthew Pounsett <matt@conundrum.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZYngzy-l0IKEbmtvGSRJrHg37to>
Subject: Re: [DNSOP] Working Group Last Call on draft-ietf-dnsop-terminology-bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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: Fri, 06 Jul 2018 04:15:31 -0000

On Jul 5, 2018, at 19:38, George Michaelson <ggm@algebras.org> wrote:

> Only the zone authority can publish a DNSSEC signed zone.


I don't know what this means exactly, but I think it's wrong. I will
illustrate my thinking by using some of these words (like "publish")
in the way that I understand them, to see if that helps. So I am not
arguing; I'm describing different usage.

Any nameserver can publish any zone they want. There is no claim,
there is only do. DNSSEC RRSets are not special in this regard. They
are just RRSets.

A client might send a query to a particular server because it was sent
that way by referrals or by local configuration. Clients might not
send queries to a server at all. The server can still be said to
publish a zone.

Only someone able to exercise the private key that corresponds to a
published trust anchor can generate signatures that anybody can
validate. Signing RRSets is a different function from publishing a
zone.

Multiple copies of a private key might be exercised by multiple
different actors who can each produce different signed zones with the
same alex owner name, which clients can successfully validate using
the same trust anchor. You could argue that such a key is not very
private, and I might agree. (See also the multiple-ZSK experiments
conducted in the Yeti project for other examples.)

Root server operators publish the signed root zone. They are not able
to exercise private keys used by PTI and Verisign to generate the
various RRSIGs in the root zone. That is ok.

Many TLD operators generate signed zones that are published on
nameservers operated by third parties (e.g. as commercial DNS
operators, for fee). Those third party operators publish the zones,
but don't have access to the private key. That is ok.

> Anyone can claim to publish a view of a non-DNSSEC signed zone.

I don't know what "publish a view" means. A "view" is BIND8/9
terminology that describes which zone data to publish to particular
sets of clients. The things being published are the zone data, not the
views.


Joe