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

[Manu Bretelle <[e-mail]>]

On Wed, Nov 11, 2020 at 1:20 PM Tony Finch <[e-mail]> wrote:

> Manu Bretelle <[e-mail]> wrote:
>
> > Having this as an ID or possibly a github repo may make it easier to
> refer
> > to/iterate than just this email.
>
> Yes! https://github.com/fanf2/draft-dprive-adot


Thanks!

>
>
> > I had attempted to quickly categorize some of those approaches (albeit a
> > much smaller list) in a matrix in [0] but did not follow through since.
> >
> > [0]
> https://datatracker.ietf.org/meeting/104/materials/slides-104-dprive-dot-for-insecure-delegations-01
>
> Ah, I haven't been paying enough attention to meetings so I missed this! I
> think I need the speaker notes to understand it properly :-)
>

Totally fair, pretty sure there were no speaker notes ;) . The
presentation is available at https://youtu.be/MIapQ6UXrdg?t=5387 .
Originally, there was this draft
https://tools.ietf.org/html/draft-bretelle-dprive-dot-for-insecure-delegations-01
and the solutions in the slide deck were compiled from feedback/ideas that
came up while talking with other folks.


>
> Your title "DoT for insecure delegations" is interesting: one of the
> problems with what I have written so far is that it is too much a post-hoc
> justification for using TLSA records to support ADoT. So I have built
> nameserver authentication on top of TLSA on top of DNSSEC.
>

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:
https://mailarchive.ietf.org/arch/msg/dns-privacy/FdUhMUGNR-CybLrTBQfgGjq0ZY0/

My TL;DRed notes, in the context of serving zones across name servers in
(multiple) out-of-bailiwick zones, that I think echoes Brian's more
throughout description:

Other approaches to signalling DoT support to the recursive nameservers may
be through the presence of TLSA record, special record at the name server
side. In the end, the name server zone owner will have to be authoritative,
such authoritative answer can only be validated if it is signed. By
separating zones from nameservers, one can provide DNSSEC signing at the
name server zone level without having to enforce it at the zones which are
served. Having multiple name server zones would:


   - allow enabling DNSSEC on a subset of the nameservers without risking
      impacting all the DNS traffic.
      - allow to stage key roll on a subset of the nameservers, and
      ensuring that in the worst case, only a subset of the traffic is impacted
      in case of mishap.




> One of my unstated assumptions is that DoT will be problematic for TLDs,
> and (with QNAME minimization) it matters more for leaf zones, so it is
> likely to be deployed there first. But DNSSEC is deployed to a much higher
> proportion of TLDs than leaf zones, so there's a good chance I'm wrong.
>

yeah, and this is where zones hosted by DNS providers may benefit of this
hybrid approach if the providers are supporting DNSSEC for their name
server zones. But I just quickly checked Route53 and Google Domain, and
none of them have their NS names signed.

Manu

>
> Tony.
> --
> f.anthony.n.finch  <[e-mail]>  http://dotat.at/
> Shetland Isles: Southerly 6 to gale 8, decreasing 4 or 5 later in west.
> Rough
> or very rough. Rain or drizzle. Moderate or poor, becoming good later in
> west.
>