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
>