Re: [dns-privacy] how can we ADoT? (with github url)

Manu Bretelle <> Thu, 12 November 2020 18:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89DC33A0AAF for <>; Thu, 12 Nov 2020 10:59:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.848
X-Spam-Status: No, score=-0.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SHORTENED_URL_HREF=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WgbSi4ITTf-h for <>; Thu, 12 Nov 2020 10:59:33 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7E6353A08BB for <>; Thu, 12 Nov 2020 10:59:33 -0800 (PST)
Received: by with SMTP id s24so7122963ioj.13 for <>; Thu, 12 Nov 2020 10:59:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b0lQoKHmO97GwUsKEN4Y7N2yglanK1xJB/VGKUNvYNo=; b=CURdhhCVPegFN6FA+878RdFlEb+N+yWdIu+3XNh2Rd7MCj3nKuNWwwYK0XbQslI/xc m93hSrKScvqbN/zjrvk3lxxrsZKAk7y68HZWsf7V+pRh4e9oGcm1Zeh4ZhD4PhzJVBzJ ihdDdIave5MX49tpo81yDmKxJ+0FtSqxmQFL8cPhkv/NNvBVuSQCro4swxHKq/B1++s/ 45LXLOxjyao5zDsKk+musUZmwbiDb4+DLncS4kL9Xu2gr6Z8t+YdmEfJk66Zj4v+Bwrr YUwEddpaN/tjbbvUbVzAscAkZ7g6ncPSJEUVqEYpHZ7c6oxpe1Ck57R9iHfhSVane4pJ TsAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b0lQoKHmO97GwUsKEN4Y7N2yglanK1xJB/VGKUNvYNo=; b=bJhBXbZFuann6f9OvVoCLhOGTKhxJgcSC/VifHTc6edASpkfAf/V0cQzvJ4XpezCrN l8TFYyLghJgmw4RyxPeHHCB8WNkFGsXeGIfaitI1mCwsFleEwxYGE2+Gwgu7IHNWxC6c 8GDiJBm83sd/L6Ssrg67ikOUEjo3oohPkXPMHPDw/EONP13dpYh7yAZtzhz4hX343LzL yXIwT7dIPLD1VflvhOlh1ox1FvMR7p5ZlTld3GBKKejqey0OfVOhv4Y1ZBmDt68z3g4l 3ZdcmHD5VfAqLTBdfw0BhrIB9yhPMyoQqv3sqC+kGgZXL0Mq3+p9E2e/cMoo22NmxW6a 6bEA==
X-Gm-Message-State: AOAM5313IRBIWiuB67dvgJuLvz16IgeCFJr7wsyoESZK+MO+dak/YLI/ ZK/r/tiR9+y8QOk6YAtu+WhIkEEtgUtKKZvrB/s=
X-Google-Smtp-Source: ABdhPJx+WBdw9yir6w12s7N533wsOCKO/CwIl83rJCBNHK+bI4POFJRuHzb7l0Lfqeg9qOnld278W1XN4APiGZqlgOg=
X-Received: by 2002:a02:bb93:: with SMTP id g19mr994346jan.142.1605207572557; Thu, 12 Nov 2020 10:59:32 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Manu Bretelle <>
Date: Thu, 12 Nov 2020 10:59:21 -0800
Message-ID: <>
To: Tony Finch <>
Cc: DNS Privacy Working Group <>
Content-Type: multipart/alternative; boundary="0000000000002735f205b3ed837e"
Archived-At: <>
Subject: Re: [dns-privacy] how can we ADoT? (with github url)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Nov 2020 18:59:36 -0000

On Wed, Nov 11, 2020 at 4:00 PM Tony Finch <> wrote:

> Manu Bretelle <> wrote:
> >
> > Totally fair, pretty sure there were no speaker notes ;) . The
> > presentation is available at .
> > Originally, there was this draft
> >
> > and the solutions in the slide deck were compiled from feedback/ideas
> that
> > came up while talking with other folks.
> Ooh, that video has lots of ideas, thanks! I think most of them are
> slightly different angles on approaches that I rejected in my notes. (how
> do I do a wry emoticon?) I'll try to summarise - please forgive me if I
> have misunderstood...
>   * DSPKI: vaguely dnscurve flavoured delegations, but putting an X.509
>     SPKI into a new delegation RRtype. Comes under my "new kind of
>     delegation" heading.

The penultimate slide is a dnscurve like approach.

>     (There's a twist that DSPKI seems to have an authenticator per zone,
>     so all servers are expected to share the same private key?)
yes and no, you could have multiple DSPKI records, but it is definitely an
all or nothing, as in all servers would need to provide DoT.

>   * Do9: per-server encryption hint without authenticator inside DS
>     records. Most of the badness under my "new DS algorithm" heading,
>     but with less key rollover churn. WebPKI authentication.


> Joe Abley emphasized what I called the scalability issue. Wes Hardaker
> made a slightly different point about correctness and synchronization of
> apex and delegation records. Wes's point kind of strengthens the
> scalability issue: a design that avoids per-zone configuration of any
> kind for scalability reasons also avoids delegation mismatch problems.

yes, anything that will involve the parent will be a nightmare to keep
synchronized unless stuff like CDS, CDNSKEY ... hence CDSPKI work, well as
much as synchronisation is concerned.
The "cloud provider" case, e.g few name servers for many zones is also
tricky. I think in those cases, TLSA may be the best bet as this is under
control of the nameserver, not the zone operator. Then there  may be issue
with being able to opt people in/out. I think in any cases, if you want to
be able to gradually enroll your customers while giving the the choice to
not be enrolled, you essentially need to provide them with a new NS that
supports ADoT and have them move over.

> Watson Ladd made a good point about decoupling signalling from
> authentication. My prejudice was that if you are publishing a 1 bit ADoT
> signal in the DNS you might as well publish a 256 bit authenticator; now
> that I have gone through the options in detail I still think that is true.
> And I think it implies that any approach to ADoT based on in-band
> signalling should avoid relying on any records published in the DNS,
> because then the in-band signal no longer does anything useful.

 Decoupling signalling from authenticating could actually let zone owner
decide to not do ADoT even though the provider supports it.

> [ I've been very bad at looking for and citing previous work, sorry
> everyone... I belatedly realise the datatracker doesn't list expired
> drafts, oops ]
> > Speaking of which, I think Brian Dickson did a good job of describing an
> > "hybrid" approach which I had notes of, but never got to write down
> > properly. Here is the link:
> >
> Yes, I think Brian's description is basically the same as what I have in
> mind. On top of that I've added a little complication, `dot--` hints so
> that when a delegation requires glue, a resolver can still connect
> directly over TLS without first getting the TLSA records. I am unsure if
> these hints are really needed...

That hint could be downgraded, but if not, can be used to fetch the TLSA
record over an unauthenticated TLS connection and then validating it. I
suppose it just obfuscate the  zone, which may be useful *if* multiple name
server names are behind the same IP and/or name server name matches the
zone name (because TLSA record would be against name server name, not zone).
Unless the query to the parent zone was using ADoT, that information may
already be known from someone on-path.


> Tony.
> --
> f.anthony.n.finch  <>
> Channel Islands: South to southeast 6 to 7, locally gale 8 with gusts to
> 50kt,
> veering west to southwest 5 to 7 before midnight, decreasing 4 to 5 around
> dawn, locally 6 mid-channel, backing southwest to south in the afternoon.
> Rather rough to rough, occasionally moderate in the south and east,
> becoming
> slight in the south to rather rough in the north by midday, perhaps locally
> rough mid-channel, with a low swell throughout. Rain, locally heavy,
> clearing
> before midnight to isolated showers. Good, occasionally moderate to poor
> this
> evening.