Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

Brian Dickson <brian.peter.dickson@gmail.com> Thu, 06 February 2020 17:57 UTC

Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46DF120995; Thu, 6 Feb 2020 09:57:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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_NONE=-0.0001, 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=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 Bfec7bTdiBSx; Thu, 6 Feb 2020 09:57:19 -0800 (PST)
Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 F291E120994; Thu, 6 Feb 2020 09:57:18 -0800 (PST)
Received: by mail-ua1-x92e.google.com with SMTP id 59so2573612uap.12; Thu, 06 Feb 2020 09:57:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKjhaI5uVFcTO5eExbG8Z/cFoZV/IKaObWtaZEJ/p+Y=; b=h+Nf/cxIKXpcKtoT6CPbVQbjmgZv1bXYEsfvaGnu0kNmFwfOu96KnJb6viKu9E42U8 njiwWzEerikMqvL7sUmqwh4JfGZBcEnmiwfBVZLorWtTmvHscYlG7tnX9t7na5c0adDL 5GRx4L80ilpz3vdLz6v9fezFrWJzPn1SM6DxC/Ksc+OjI9JejNzbXwhE9FmkGGBwVWJ2 K+HQc08SeKkW1ubDJL3XiQz57Nbbi9t0wQwkEZ4LFq1l6yRE5cUQqay3+lPqblcJBlyK 1Irapemd3mPhQZIePeOOt8trFJKfBa8bBNLv4mjwwwgC5TD2zyqFcg9HN+0EZZwl+4Z4 zwHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKjhaI5uVFcTO5eExbG8Z/cFoZV/IKaObWtaZEJ/p+Y=; b=pH/3m4EOMyGVIYKyXg13pJcgOxL71msRJ2D2m8xlzAOI8LwciAUGEaDZnHWSziZMUP 1/sj6QMBHRKGOgVfLUVK+91btsBd3RNfxRS/zCks/OeSbcyCkWDHFRijOeehl8wp5mex X8FhIdckNGIYKGUSuspPofm8FqoxZ8G2xb5HJ/1TOgF0jiptYbRpg0N0BcIwFwXRSA1i W4FKNDz+d0hQnQve1YF5BYfmZgI31lwkMSToaTCMMaUHEOYM1/sVJHHBBSlDkPN/kIjp zDRhN8mQ5Z36dW7+6djb2FeVc6cWzYRiJYyzuYwvuaqbEvuE9n3KPgPjptuzkq3KqpA2 1TXw==
X-Gm-Message-State: APjAAAUaj39g502iuzLDEk14jj5eEK1GjNZXrryQ2vJmQWWHFhH6RhSh trkv4sXioaNAs4wxDOITZSDKIuwZGLtwfE3LCt4=
X-Google-Smtp-Source: APXvYqymmwy14lbBkoJaSrH+kbuGjpd+mIp0hZtq1D4kWEVEWKB+pet6ZtHsHIq4Q1wWiDpnrNvq7cITtRxpUoOglWw=
X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr2335942uar.62.1581011838100; Thu, 06 Feb 2020 09:57:18 -0800 (PST)
MIME-Version: 1.0
References: <158096547226.30514.2103023305468871108.idtracker@ietfa.amsl.com> <CAH1iCiqLwP8UOJe_vWQAr7iu8j7LF2Y4+386XNimM+3wJ-2RzQ@mail.gmail.com> <9fe99917-347b-ab79-7a9c-3e8da67a5246@nostrum.com> <364cf548-9114-fcb3-52b6-a73be08b55c4@nostrum.com>
In-Reply-To: <364cf548-9114-fcb3-52b6-a73be08b55c4@nostrum.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 06 Feb 2020 09:57:06 -0800
Message-ID: <CAH1iCirzvzQUAcbctzC4Bete_mDicT7MYJL5vnaSFZnVNAUbPg@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, draft-ietf-dprive-bcp-op@ietf.org, dns-privacy@ietf.org, The IESG <iesg@ietf.org>, dprive-chairs@ietf.org
Content-Type: multipart/alternative; boundary="000000000000fee745059dec00de"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/plA9Pw8S2GsMLXPCqi9gtd1T008>
Subject: Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 Feb 2020 17:57:21 -0000

On Thu, Feb 6, 2020 at 9:31 AM Adam Roach <adam@nostrum.com> wrote:

> On 2/6/20 09:08, Adam Roach wrote:
> >
> > For the specific example chosen, it's been made pretty clear over the
> > years that at least the clients for the specific service you cite have
> > no interest in incurring this additional cost. If that's the working
> > group consensus, then I have no interest in over-riding it. But
> > ignoring operational realities seems kind of ivory tower-ish, which
> > feels like the kind of thing that undermines the general credibility
> > of the rest of the document.
> >
>

Could you please be more specific?

When you say "for the specific service", do you mean DNSSEC?

And do you mean the signing of DNS zones using DNSSEC, when you refer to
clients of that service?

Perhaps you missed my microphone comments at the last IETF?

Specifically that GoDaddy will be turning on DNSSEC for the vast majority
of its DNS hosting customers?

This represents about 40% of the DNS zones on the Internet.
(The exact time frame is not set in stone, but we expect this to be done in
the first half of 2020.)

Given that this significantly alters the calculus, I don't think that is a
good enough reason to object in and of itself anymore.

The other aspect of this is the asymmetry involved in the defenses against
impersonation:

   - The choice to sign a DNS zone is under control of the zone owner
   - The choice to deploy RPKI on routes (to protect against BGP hijacking)
   is under control of the IP prefix holder
   - Both methods rely on third parties to cooperate to achieve the
   protections offered
   - RPKI routing filters are now widely deployed, and RPKI registrations
   are substantial
   - The remaining issue is DNSSEC validation; many (most?) of the public
   recursive operators do this already

The logic should be, defend against all feasible attacks, rather than
justifying the non-defense in one area (DNSSEC for DNS) based on the
assertion that another area is not being defended (RPKI for BGP).

Brian


>
> I realize that my editing made one of the pronoun antecedents here go
> away. The second sentence should have said something more like "If
> keeping the current text is the working group consensus..."
>
> /a
>
>