Subject: [dns-privacy] Fwd: New Version Notification for draft-dickson-dprive-adot-auth-02.txt

From: Brian Dickson <[email-masked]>
Date: Fri, 17 Sep 2021 20:48:52 -0700

Hi, DPRIVE folks,

I have been working on the ADOT signaling and TLS validation problem.

This draft relies on a couple of short drafts I have submitted in DNSOP,
for the "unsigned NS record" and "unsigned glue records" problems.

There are a couple of mostly superficial additional RRTYPEs to support this
(a SVCB binding, and a TLSA aliasing), plus some EDNS options to reduce
round trip times.

I've included numerous examples, complete except for literal RDATA from the
examples for a few record types.

(I had said a fair while back, around the last IETF, that I would be
submitting something. I had some time off for vacation, and a short COVID
breakthrough, but finally got the drafts submitted.)

I think the scaling factors and round-trip times speak for themselves. The
methods are equally suitable for small or large DNS operators, and provide
full authentication with downgrade resistance.

It is not dependent on WebPKI, requires DNSSEC usage on the DNS operator's
infrastructure zone (where the addresses, signaling, and TLSA data are
served) but is otherwise very light on changes required beyond new RRTYPE
support, and even then involves new instances of existing types.

I think it's fairly straightforward, but it is difficult to tell without
getting feedback, so please let me know what you think.
(The source is markdown, processed by mmark, and managed on github. Anyone
interested in contributing or commenting there, please contact me.)

Brian Dickson

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Sep 17, 2021 at 8:27 PM
Subject: New Version Notification for draft-dickson-dprive-adot-auth-02.txt
To: Brian Dickson <[email-masked]>

A new version of I-D, draft-dickson-dprive-adot-auth-02.txt
has been successfully submitted by Brian Dickson and posted to the
IETF repository.

Name:           draft-dickson-dprive-adot-auth
Revision:       02
Title:          Authenticated DNS over TLS to Authoritative Servers
Document date:  2021-09-17
Group:          Individual Submission
Pages:          17
URL:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.txt
Status:
https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
Html:
https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.html
Htmlized:
https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
Diff:
https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-02

Abstract:
   This Internet Draft proposes a mechanism for DNS resolvers to
   discover support for TLS transport to authoritative DNS servers, to
   validate this indication of support, and to authenticate the TLS
   certificates involved.

   This requires that the name server _names_ are in a DNSSEC signed
   zone.

   This also requires that the delegation of the zone served is
   protected by [I-D.dickson-dnsop-ds-hack], since the NS names are the
   keys used for discovery of TLS transport support.

   Additional recommendations relate to use of wildcard records for
   efficiency and scalability, and new EDNS options to improve round
   trips and signaling between clients and resolvers.

The IETF Secretariat

---

From: Peter van Dijk <[email-masked]>
Date: Tue, 21 Sep 2021 14:15:47 +0200

Hello Brian,

many thanks for a completely worked-out protocol. Please find some
comments below. A further reading of the document might yield more
comments, but this is what I have now after my first reading.

On Fri, 2021-09-17 at 20:48 -0700, Brian Dickson wrote:
> Status:         https://datatracker.ietf.org/doc/draft-dickson-dprive-adot-auth/
> Html:           https://www.ietf.org/archive/id/draft-dickson-dprive-adot-auth-02.html
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-dickson-dprive-adot-auth
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-dickson-dprive-adot-auth-02

Quotes below are from the document.

> NSECD 	New 	OPT RR 	N 	Signal desire for NSEC(3) for [RFC8198]

I do not understand what this does that the DO bit does not already do.

> Use of DS records [I-D.dickson-dnsop-ds-hack] for the protection of the delegation to the authoritive name servers

Of course, Ben's DSGLUE would work here too. The key differences between ds-hack vs. ds-glue appear to be:
* hashing vs. verbatim
* NS records only vs. flexibility (with NS/A/AAAA and possibly TLSA as good starting points)

I prefer DSGLUE, but as far as I can see it would be a drop-in replacement in your protocol.

> Use of "glueless" zone(s) for name server names' zone [I-D.dickson-dnsop-glueless]

I see how this is a relevant part of how your setup fits together, but I don't like this requirement, and I believe using DSGLUE instead of ds-hack would remove this need, and allows dropping -glueless from the set of documents.

> This would allow DNS caching to avoid repeated queries to the authoritative server for the zone containing the DNS server names, to obtain the TLSA-type information.  

This is not true for the example zone data given. The ns1-4 A/AAAA records would prevent expansion of the wildcard for the TLSADOT record. The same problem appears with DNST in section 6.3.1. Given that, having DNST as an alias for SVCB, and TLSADOT as an alias for TLSA, seems mostly pointless to me.

(That said, svcb-dns defining that '.' maps to _dns.ns1.example.com, not ns1.example.com, is very inconvenient to operators. The dot form is basically useless in svcb-dns. So, in that regard, I do like DNST.)

> The value "Force" indicates the server should attempt to use ADoT, and return a failure code of XXXX and an EDE value of YYYY if the authoritative server does not offer ADoT, or any other ADoT failure occurs.  

'the authoritative server' is too handwavy. Can 'Force' even work until all TLDs have encryption?

I'm not sure I like section 8 at all. It feels like encoding policy at the wrong layer.

Conclusion: ignoring TLSA for a moment, this protocol appears to be just a few changes away from my/Paul's proposal (if I generously include ds-glue-or-similar in that). It is very good to see this variant written out, so that it can be judged at its merits, which has been hard for various handwavy proposals only seen in messages in email threads.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/