Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29
Brian Dickson <brian.peter.dickson@gmail.com> Tue, 29 October 2019 04:37 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 4AAA312008C for <dns-privacy@ietfa.amsl.com>; Mon, 28 Oct 2019 21:37:43 -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 QG1Uqfk5TVQJ for <dns-privacy@ietfa.amsl.com>; Mon, 28 Oct 2019 21:37:40 -0700 (PDT)
Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 02C56120046 for <dns-privacy@ietf.org>; Mon, 28 Oct 2019 21:37:40 -0700 (PDT)
Received: by mail-ua1-x944.google.com with SMTP id c16so3392532uan.0 for <dns-privacy@ietf.org>; Mon, 28 Oct 2019 21:37:39 -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=ROrmDIkYXwFt2FmAoqQehWex+OPQJKxmyXzlnQhFNjg=; b=lxPgVXTiTr4McLkm3npL02SwUJLo23y9kmVbAyU1Hzeyt3JUivc0qwCH9MSicbqrmK P/ygWDJGCPJSX9IKvAylwN7j3IPvsCU93oxSzlyvA/sanDWfJEnjO2QdnZC/cy3kcSP/ gmO3xd2viEcJ43tkadpVK/LMj+hVtNsOeOgrdmIxC/w2XZ8YomCMx9bC3apXts1vZgvp uDX8WNKQYUu/T561+tSNqAqAQPAtHO2jqm3NOgUsVR4zrIv6pgPmWggNmHVqEJFCtfBL 7hZbhDHXwITcnktKfeF4lMAorJ2P3WSxdt4vK0/DBmYrn0eu6o0jXFqZhCreBqzeNfHy 4Axg==
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=ROrmDIkYXwFt2FmAoqQehWex+OPQJKxmyXzlnQhFNjg=; b=pxYEP+aqOhqrIeclvBCjh9LXZ7Sv/JdX/IfXqEpq/sux2PwUNlxfiVKTl1iSw+CzMI JcslT2Yhmyfvv+hLRDMZKmfUoKb/YXi3k0VqF8kaDcbmGfFbHZYRtzR38TlQB3Gih6t8 dU3Ely/9DaKfGPWTaadUBlIRCEimW+SD7sTGzcP/lHWl0nILEDQwRn6oaE+cQ1V2I29Y Gx90r5iJVHxOD6c5hpumyP8vPntO3qMSLvLMKz94Gq74rU2nJZ90uIw40jCNG8yJ59pF oDwTPmPemf9ItdgTeFC7WEZNjAaTC7vCRj+9IsEGVYZwS2lrVxUmuF4cUfaAc3GC6oKq heDw==
X-Gm-Message-State: APjAAAVcLw424hp2hjNEum9dRziKvS4YWOBfJKvJcfgAQDB23vdPhrc/ WwSsfZ7QZDKVFDP6rxEWAjXjLFAzFiP1GqWJ4kQ=
X-Google-Smtp-Source: APXvYqxv3+kqTUH6XwvenZSAyiVzNXOy1ebp8QbgCY9a8O51G2vE9aaVtNYvqTZEGGyczK69pmbM4hzYlB6+FL+sOcw=
X-Received: by 2002:ab0:189a:: with SMTP id t26mr10363087uag.87.1572323858810; Mon, 28 Oct 2019 21:37:38 -0700 (PDT)
MIME-Version: 1.0
References: <943e3973-f6a7-9f6e-a66a-33aff835bd5e@innovationslab.net> <503df6fb-b653-476f-055f-15c1a668ba36@innovationslab.net> <29aabefd-e02b-56cd-e1bd-77d44071920a@icann.org> <9f7a71e0-ff3e-0199-9f4d-c931d752f54c@innovationslab.net> <88948CDC-288C-4EB1-8419-5525F0EA601D@cable.comcast.com> <CAHXf=0o0=FrEPf0AKeMvOY=Bjprhu7byxPGZfoh99i39YFTMyw@mail.gmail.com>
In-Reply-To: <CAHXf=0o0=FrEPf0AKeMvOY=Bjprhu7byxPGZfoh99i39YFTMyw@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Mon, 28 Oct 2019 21:37:26 -0700
Message-ID: <CAH1iCioxBQQQQBzgKxOb7ktE4TiRfGCbhinKiuMih1FsGzNf8w@mail.gmail.com>
To: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
Cc: "Livingood, Jason" <Jason_Livingood@comcast.com>, Brian Haberman <brian@innovationslab.net>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000138cd60596052d5a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/roMU2U1zytLal0o966Z4DYMeElc>
Subject: Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29
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: Tue, 29 Oct 2019 04:37:43 -0000
Hi, everyone interested in ADoT, I'm planning on being on the call, although given the early hour for me I can't be sure I'll be on my game as much as usual... In the interests of getting all the ideas I have after reading the -00 draft, I thought I'd send them to the list, and maybe they can be discussed on the call, time permitting. Simple notion up front: add an EDNS flag or OPT code to signal ADoT support (or a bit field of all the supported transport types) on a given IP (analogous to the RA flag), and possibly include the canonical name(s) of the server at that IP, if the query include EDNS. This limits downgrades to on-path adversaries who block port 853 and modify port 53 traffic. Maybe SIG(0) or TSIG can further prevent downgrades by on-path attackers who would modify UDP/TCP port 53? Certificates for DoT and DoH should really be DANE/TLSA entries. We're literally talking DNS here, so it would be particularly shortsighted not to standardize on this. It also potentially decouples from any hard dependency on particular CA support matrix, notwithstanding that the authoritative server might be using a CA-issued certificate. Having the ability to validate without needing to unilaterally trust some particular set of CAs is a feature not a bug. State exhaustion protection mechanism, optionally use TCP cookies during handshake, regardless of TLS or not. This limits the TCP impact of needing established connections to do the TLS stuff to legitimate TCP connections only. Servers can limit the number of connections doing TLS handshakes, and prioritize those. The, use of aggressive timers on those prioritized connections protects against deliberate DOS via "slow transaction" attacks. Handshake-complete connections can be resumed, so making them lower priority and having aggressive connection dropping on those has comparatively low impact (since session resumption is cheaper than redoing the handshake). Experimentation is needed to establish recommendations on all the appropriate values (timeouts, number of sessions to support in each state, etc.) The rest of the ideas mostly relate to the question "when is using DoT really optional, vs strongly desirable?". I have a few suggestions along that line, as well as a few additional observations. First, there is a strong correlation between the first time any client queries a given name, the visibility of the corresponding R2A query (presuming no ADoT), and the subsequent client data traffic (even with HTTPS). The R2A (recursive to authoritative) query is a strong indicator that the name isn't cached (and may never have been cached). This correlation may not be that important per se, but identifying it as somewhat distinctive means there's a reason to potentially look at the implications of that (from the perspective of ADoT being "strongly desirable"). In contrast, very popular domain names (and qtypes) are likely to be heavily served from the cache. If cache refresh (what was once identified in the HAMMER draft) is done for popular cache entries, there would no longer be any identifiable query triggering the R2A lookup, and in particular no timing side channel for identifying even a single DNS client. What I'm suggesting is, using ADoT predominantly (or even exclusively) for "cold cache" lookups, and doing "cache refresh" lookups without ADoT, is one way to minimize the TLS overhead, which incurs a cost on the authority server (mostly CPU) and a penalty on the recursive (mostly latency, and maybe some CPU). Refresh without TLS would have lower latency, IMHO. IMHO, the same rationale for "cold cache" also applies to "ECS" (EDNS client subnet). First instance (of a particular ECS parameter value), use ADoT; refresh, ADoT is optional. The other question (observation?) is that ADoT is a poor substitute for DNSSEC. I.e. unsigned zones might seem like attractive reasons to force DoT for transport, but doing so would basically amount to "security theater". It would also discourage, rather than encourage, use of DNSSEC validation. It would be justifiable for an authority operator to respond "REFUSED" for ADoT queries doing "refresh cache" queries on unsigned domains, at least during periods of heavy load. Or maybe some new error code or EDE to signal "retry on non-TLS connections". It remains an open (and perhaps interesting) question of the relative overhead of DNSSEC validation when compared with TLS transport. It might be interesting to compare those based on crypto algorithms (for negotiated TLS connections, and for DNSSEC zones), and based on various TTL values. Having validation of DNSSEC signed zones, on popular domains being refreshed without ADoT, would potentially be the "sweet spot" for security and privacy. Security, by having cryptographically signed zone data, and privacy by the aforementioned "cold cache" and "cache refresh" distinction. This might be where the EDNS signaling available directly between the recursive and authoritative, would allow the authoritative server to make the informed decision to reply with UDP instead of over the ADoT connection, if/when it experiences significantly increased load. The recursive could always try to use ADoT, but get signal(s) from the authority server to limit ADoT to "cold cache" queries only in response to load problems. Finally, I'd like to announce the following: *GoDaddy now has four ADoT servers in its OTE environment.* They are ns01/ns02, and pdns01/pdns02 in ote.domaincontrol.com, with domains dnsczar.com and sheldns.com on those respective nameserver pairs. The TLS certificate names match the NS names for those domains. The test domains are also DNSSEC signed. (The domaincontrol.com zone is not yet signed, so no DANE/TLSA for the certs just yet.) Please feel free to test against those domains, and feedback on that testing is being actively solicited. Send feedback to bdickson1@godaddy.com please. All credit for the DoT goes to my colleague Michael Sheldon (as do all the GoDaddy DNS software kudos.) We are supported by our excellent ops team including Brian King, Jason Lynch, Frank Even, and Tyler Stanton. Brian Dickson On Mon, Oct 28, 2019 at 3:24 AM Alexander Mayrhofer < alex.mayrhofer.ietf@gmail.com> wrote: > I've just posted the -00 individual submission version: > > https://tools.ietf.org/id/draft-lmo-dprive-phase2-requirements-00.txt > > Sorry for the delay, but i hope that people still have some time to > look through that draft. > > best, > Alex > > On Fri, Oct 25, 2019 at 8:59 PM Livingood, Jason > <Jason_Livingood@comcast.com> wrote: > > > > I just submitted my final changes to Benno and Alex and put the ball in > their court to send something over the weekend or on Monday morning in > Austria or the Netherlands. It is a very early -00 and so intended to > mostly spur WG discussion. > > > > Jason > > > > On 10/25/19, 11:05 AM, "dns-privacy on behalf of Brian Haberman" < > dns-privacy-bounces@ietf.org on behalf of brian@innovationslab.net> wrote: > > > > Hi Paul, > > > > On 10/25/19 10:27 AM, Paul Hoffman wrote: > > > On 10/25/19 6:25 AM, Brian Haberman wrote: > > >> > https://datatracker.ietf.org/doc/agenda-interim-2019-dprive-01-dprive-01/ > > >> > > >> On 9/25/19 10:45 AM, Brian Haberman wrote: > > >>> All, > > >>> We are going to hold a DPRIVE virtual interim meeting on > Oct. 29th > > >>> at 4:00pm CET / 11:00am EDT / 8:00am PDT. The three agenda items > are: > > >>> > > >>> - Review updates to the BCP based on WGLC comments, > > >>> - Review updates to 7626bis based on WGLC comments, > > >>> - Discuss recursive-to-authoritative requirements (-00 draft > forthcoming). > > > > > > Will we be able to review the forthcoming > recursive-to-authoritative requirements draft before the interim meeting? > > > > I have asked the authors to post either a -00 draft or a doc on > GitHub > > before the interim. > > > > Brian > > > > > > > > _______________________________________________ > > dns-privacy mailing list > > dns-privacy@ietf.org > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy >
- [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] DPRIVE Interim: 10/29 Allison Mankin
- Re: [dns-privacy] DPRIVE Interim: 10/29 tjw ietf
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Rob Sayre
- Re: [dns-privacy] DPRIVE Interim: 10/29 Eric Vyncke (evyncke)
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- [dns-privacy] ADoT requirements for authenticatio… Paul Hoffman
- Re: [dns-privacy] ADoT requirements for authentic… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Hoffman
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Christian Huitema
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Watson Ladd
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ralf Weber
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] ADoT requirements for authentic… Tony Finch
- Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] ADoT deployment at the root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] ADoT deployment at the root Ted Hardie
- Re: [dns-privacy] ADoT deployment at the root Warren Kumari
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] ADoT deployment at the root John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Stephen Farrell
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman