Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld

Ted Lemon <mellon@fugue.com> Thu, 18 June 2020 18:35 UTC

Return-Path: <mellon@fugue.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 B58FA3A0E17 for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 11:35:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 dLHoK_sWawPV for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 11:35:06 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 DFDA53A0E16 for <dnsop@ietf.org>; Thu, 18 Jun 2020 11:35:05 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id x62so1913023qtd.3 for <dnsop@ietf.org>; Thu, 18 Jun 2020 11:35:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pRBEGFTApGXVIuzDxuWwiPs5yEbY3K3ti3WS4fZVc8I=; b=snxsBhv/ogvY8CnTe+yEbw3m23nsTmf1CUcU+u+hcH2tN5vU6B02OuxEftvOkozq79 vCp6TuZw9kz5k40cTnAucAh9osjbuNO6etfgQJmupLNl7Xv16iwALrsa3l+qys6v5bIU RVqp2uw6kh9l3MHirT91+awVmh5HpXcJznh9kwzszimmhV6oBVYoDtuV0UrxnPBO7dxD ZTHxEuEaLgPb5SGHL9HpTgT+nCvdORQeY6tES6OmY/H4/wh1jA1C95e0R8N6uscBsON8 +Tel3Vxq7YiV4QvtklaiMoUsDxG8Tqs4mEV2LqKReWU4iTQYk71nLW1qWfbympyLhAMR LS7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pRBEGFTApGXVIuzDxuWwiPs5yEbY3K3ti3WS4fZVc8I=; b=TYoKbh3TfdnSPidRdTqnanNr3noPleLwFJyGMfC2Dji+jBRqmM7J+cBTqVKaDLM9WJ Vq5Bju7BeUecT+okEcVWHcF+o5TtQsIQMQssG7mLSbzQCxdkijs41n5PD2rndbajv9n2 JUnZKoSWzkTjkV6Efrd2ePq3WK1L6qwdsxAa9zh5O6vgmNTiOzAHLon+N4aKfI/A4g63 sJ2QCcyvog2x8X5+L1ReuK6XdhkPXWzRFpdlBx6vv2xbEatqq30uibjhvo+lSEyXEQ7k FcMWYUZG3qsMCUBhxrWKK3fFP/Q+P61/0bjIxUlWxmcAhmKhG5K0dPTrq6JwuVI0I3xo GZrg==
X-Gm-Message-State: AOAM530/DLHnfUUIoZcNY54UQhI0Ok712gVDqpjSxJ+wnEws7GZeU5L1 JrcwHGRvfD5l1ssfPHOPNr5lZw==
X-Google-Smtp-Source: ABdhPJwQLVQIU6gYbpZL9VToRiqp186Uyuu9su7YYM6jEif37VZ2qqCmUIv9GB+dYMbBjJ/ejA9vPg==
X-Received: by 2002:ac8:1b99:: with SMTP id z25mr5864719qtj.209.1592505304847; Thu, 18 Jun 2020 11:35:04 -0700 (PDT)
Received: from ?IPv6:2601:18b:300:36ee:48ca:bd69:ffe9:aecb? ([2601:18b:300:36ee:48ca:bd69:ffe9:aecb]) by smtp.gmail.com with ESMTPSA id i19sm3725075qkh.71.2020.06.18.11.35.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2020 11:35:04 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <5CF5832C-399C-43ED-B9F2-2E15524AD5AE@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_37D3BF35-1536-483A-8511-5511E3E0FDFA"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Thu, 18 Jun 2020 14:35:03 -0400
In-Reply-To: <CAHw9_i+XbjZc-QbhL1n=LAmM9mcTXp_jsQXd1q_pYkk+N_21Ug@mail.gmail.com>
Cc: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>, dnsop <dnsop@ietf.org>, Roy Arends <roy@dnss.ec>
To: Warren Kumari <warren@kumari.net>
References: <78f0cb84-f1b3-43c1-0798-c2c8ee55e1e6@nic.cz> <FE1E6C98-8B6C-49D1-AB17-729EA1B10A6C@fugue.com> <CAHw9_i+XbjZc-QbhL1n=LAmM9mcTXp_jsQXd1q_pYkk+N_21Ug@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mC3APNYJ08k204MOwipsAZzqnsQ>
Subject: Re: [DNSOP] Call for Adoption: draft-arends-private-use-tld
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: Thu, 18 Jun 2020 18:35:08 -0000

On Jun 18, 2020, at 2:24 PM, Warren Kumari <warren@kumari.net> wrote:
> ... and I should point out that this was one of the arguments in
> https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3 <https://tools.ietf.org/html/draft-wkumari-dnsop-internal-00#section-4.3>
> for an (insecure) delegation (just like home.arpa has). Currently
> operating system vendors (and similar) cannot realistically ship
> validating stub resolvers - having BYOD users suddenly unable to
> resolve www.corp on your shiny new phone/tablet/laptop results in
> outrage, and customers buying your competitors widget instead.

This is another way of framing the issue. What I’m trying to get at is that we should be telling people how to do this in a way that doesn’t break validating resolvers. At least, I think we should. I think there are two facets to this:

1. If your stub resolver validates, it must be possible to provision a trust anchor for a private zone.
2. When you set up a private zone, you should use a zone the existence of which isn’t securely denied.