Re: [Add] [Ext] Updated charter proposal for ADD

[Brian Dickson <[e-mail]>]

On Wed, Jan 15, 2020 at 12:03 PM Rob Sayre <[e-mail]> wrote:

> On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling
> <[e-mail]> wrote:
>
>> On Wed, Jan 15, 2020 at 19:24 Rob Sayre <[e-mail]> wrote:
>>
>> > Right now, my DNS server is 192.168.86.1, and encrypted DNS seems
>> designed to bypass it.
>>
>
> Well, a lot of networking products (both consumer and corporate) have an
> unencrypted DNS server on a private IP.
>
> I was wondering how the certificates would be constructed if they wished
> to offer DoH or DoT. I know public services are able to get certificates
> with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for
> 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering
> how private networks will offer encrypted DNS, and whether the debate
> around the security considerations is important.
>
>
Certificates can be self-signed.
Self-signed certificates' fingerprints can be published in any
corresponding DNS zone as TLSA records with the right subtype (2 or 3) that
does not require PKI.
Names for the DNS zones, certificates, and resolvers' host names can be
from private-use portions of the namespace (such as has been proposed for
use in the reserved portion of ISO 2-letter codes, like .zz).
The client security can then be reduced to learning or distributing DNSSEC
trust anchors for resolvers, including possibly doing "trust on first use"
methods and well-known names.
I.e. client queries well-known name for a pointer to the resolver's own
name, along with a corresponding trust anchor for that name (name of a DNS
zone).
Once the trust anchor is available, everything else can bootstrap from
that, including TLSA records (which give TLS fingerprints for certificates,
which would be self-signed and validated without PKI, using the TLSA
mechanisms.)

I'm doing a proof of concept on this as we speak.

Brian