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, 05 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
- Re: [DNSOP] Working Group Last Call on draft-ietf… Suzanne Woolf
- Re: [DNSOP] Working Group Last Call on draft-ietf… Vladimír Čunát
- [DNSOP] Working Group Last Call on draft-ietf-dns… Suzanne Woolf
- Re: [DNSOP] Working Group Last Call on draft-ietf… Dick Franks
- Re: [DNSOP] Working Group Last Call on draft-ietf… Paul Hoffman
- Re: [DNSOP] Working Group Last Call on draft-ietf… Paul Hoffman
- Re: [DNSOP] Working Group Last Call on draft-ietf… Vladimír Čunát
- Re: [DNSOP] Working Group Last Call on draft-ietf… Dick Franks
- Re: [DNSOP] Working Group Last Call on draft-ietf… Sara Dickinson
- Re: [DNSOP] Working Group Last Call on draft-ietf… Matthew Pounsett
- Re: [DNSOP] Working Group Last Call on draft-ietf… Joe Abley
- Re: [DNSOP] Working Group Last Call on draft-ietf… Kal Feher
- Re: [DNSOP] Working Group Last Call on draft-ietf… Dick Franks
- Re: [DNSOP] Working Group Last Call on draft-ietf… George Michaelson
- [DNSOP] Fwd: Working Group Last Call on draft-iet… william manning
- Re: [DNSOP] Working Group Last Call on draft-ietf… Joe Abley
- Re: [DNSOP] Working Group Last Call on draft-ietf… fujiwara
- Re: [DNSOP] Working Group Last Call on draft-ietf… Paul Hoffman