Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 01 November 2019 15:35 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 634AC120227 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:35:09 -0700 (PDT)
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 ShfJk2TFQfcC for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:35:04 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 B902412010C for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 08:35:04 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id w25so6626529vso.4 for <dns-privacy@ietf.org>; Fri, 01 Nov 2019 08:35:04 -0700 (PDT)
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=Ws0RNvJijczrxczwgrjZLWxYLu+YB1EQuF7YnjoOmoc=; b=DqmCKlmqwgyT/knWZxsFE35e+9OVCqHpR4o9OqlcjIaq6Kpycsh/vFUeI9ds5mfDus IvHHIecRVzo55E8t55ncKIkVYZtZZ8vCTFHlYvoKCqE7HhXy5Rjyi4e0prGT+emEkimo 8J4m/dZpPeUo/sv69rtSyCfZV1P3i19YGX7j7VzXLTwBRzKdGSgkw6D+0JFEPMuunPgE JZiQAD7cRgnBJfMgEN4Eev0RGHqENaXNJXdG3I3UIR7FIkI/g+KD3eI8VkYbYDD39r4o pwOqLwL55Yp6f79SkENfA3Og98d+osrJ1MisceFfy0nESLy49lv0uzpyIK96Z9uShCJE Dr3Q==
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=Ws0RNvJijczrxczwgrjZLWxYLu+YB1EQuF7YnjoOmoc=; b=b2IIl6fhyCn8LO7t03NymcDBC0VKbVBe8yoJgGuwBY//FcS77XAYSP/tB1DtPCBZnL VTPteM/RlrK8lC5UdeOl/YFPH2fvH+ucN547mBFtoO41rRKg+rdYrV2ivkAlHutsWMWb 5Aj3D3Dwo9QN0xu8PuZJ+l8/rV9RBOGn2S9JFruuIKZUWLj7iJ3xBKVT0C9ixRT30+sj L1tl5WQYYWwAvsxxVsRo7sxW/uTXHW5qWt9kZMEukGv8YUksKsdLSFQlSMZ0dxSJ4roH 0LcbIjBrhNKBJq/iBfcjFk6MwBS9SuYH0jKAwRWmURaHFrvi7vzoC6lzkQRP8zyO9+Ah X52A==
X-Gm-Message-State: APjAAAWBR2+Ae4Tk+xQ/9azimSXU6KE00zpr4gGclpRco8bSD8j6si4Y GhMCqdvqHf0bN7yV8H5cRPfcexo9xuaUKI7aDMuJHw==
X-Google-Smtp-Source: APXvYqxoHkD1SzeNcyoIDgT576JGwGr+8KwYU5fSFc63YSPJi89bAJEJqYhJR8azWyaj94ZsXVlocZvbpe+kIdXuZ1Q=
X-Received: by 2002:a67:dd81:: with SMTP id i1mr6004454vsk.136.1572622503654; Fri, 01 Nov 2019 08:35:03 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com> <20191031211222.A6422DBC1C7@ary.qy> <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com> <CABcZeBP-k23ZY=f6Lv5A+B+Z_4ar_9ea=G7O+KRriXNLUzKGqw@mail.gmail.com> <95e65176-0b80-fbe0-8409-11fada175c67@nic.cz> <CABcZeBPCMBDEGTpVULJgQEz_5Ddv27jayMxaW-fqXL3HQrqbyw@mail.gmail.com>
In-Reply-To: <CABcZeBPCMBDEGTpVULJgQEz_5Ddv27jayMxaW-fqXL3HQrqbyw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 01 Nov 2019 10:34:29 -0500
Message-ID: <CAH1iCirJHDFVEW_vdcVOyGx1KK0zkwmrUEpP=ft-gWHbx7x8fw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b23ded05964ab5a9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/OwZ_fq4SPo5I4gRbQDBVQgLvPTo>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
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: Fri, 01 Nov 2019 15:35:09 -0000

On Fri, Nov 1, 2019 at 9:13 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Oct 31, 2019 at 11:56 PM Vladimír Čunát <
> vladimir.cunat+ietf@nic.cz> wrote:
>
>> Generally speaking, I believe it's fine to add assumptions about DNSSEC
>> validation, if that makes the ADoT protocol "better" in some way.  (and
>> I expect it will)  It seems that DNSSEC will be much easier than this
>> new stuff.
>>
>
> Easier for who? The advantage of transport security in this setting is
> that the authoritative can just deploy it for all their users without any
> interaction with the user.
>

Perhaps someone who operates authoritatives at scale should speak to this?
Regarding DNSSEC ease of deployment:

   1. The DNSSEC deployment/operation constraint is a performance-at-scale
   issue. *The majority of the CPU cost of DNSSEC is on the signing, which
   does not depend on query volume.*
   2. Serving DNSSEC-signed zones may have some overhead due to NSEC/NSEC3
   responses for NXDOMAIN or NODATA (no RRTYPE) responses. *Non-NXDOMAIN
   responses are larger, which consumes bandwidth but largely has no
   incremental CPU cost.*
   3. NB: NSEC3 has additional overhead due to the requirement to hash
   queries first, which depends heavily on particular NSEC3 parameters.
   4. Enabling DNSSEC widely on authoritative servers is primarily a
   moderate cap-ex exercise, i.e. provisioning adequate signing capacity.
   5. Deploying DNSSEC for all users is very feasible, and *at least one
   significant authority operator intends to enable one-click deployment for
   all users in the very near term.*

Regarding ADoT ease of deployment:

   1. The vast majority of authority traffic is UDP today (e.g. 99% or
   more).
   2. ADoT requires TCP, and additionally requires TLS.
   3. Deploying the certificates required for ADoT is very manageable, i.e.
   easy.
   4. The operational cost of serving ADoT answers is prohibitive, due to a
   number of factors:
      1. Maintaining state, for TCP and for TLS
      2. Set-up overhead for TLS
      3. Ongoing encryption of traffic after set-up, e.g. AES computational
      cost, vs "copy bytes" (possible with DMA and no CPU)
      4. Deployment of ADoT without providing means for managing these
      costs is highly unlikely to happen
      5. Developing means to manage ADoT costs (in the standards, and in
      implementations) is highly non-trivial.
   5. *Deploying ADoT is not cheap, not easy, and won't happen fast*.
   (Cheap, easy, fast, choose two, currently zero are available to choose.)

Brian