Subject: [dns-privacy] Call for Adoptions on the 3 documents.

From: Warren Kumari <[email-masked]>
Date: Wed, 15 Apr 2015 09:08:44 -0400

Hi all,

So, the big day has finally arrived -- we are initiating calls for
adoption on the three documents. < http://i.imgur.com/SKX3P8J.gif >

For *each* of the below documents, please **clearly** state if you
would like DPRIVE to adopt it, or if you think that it will be a
distraction / not helpful.

1) Confidential DNS:
https://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/

2) Private-DNS: https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/

3) TLS for DNS: Initiation and Performance Considerations:
http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

This call for adoption will be wrapping up on April 30th.
At that point we will decide on one or multiple of the documents....

W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: manning <[email-masked]>
Date: Fri, 17 Apr 2015 15:48:59 -0700

exercising line item veto…  

I think #3 is ready to proceed.  The other two suggest fundamental changes to the DNS which need more thought.

manning
[email-masked]
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 15April2015Wednesday, at 6:08, Warren Kumari <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Ralf Weber <[email-masked]>
Date: Sun, 19 Apr 2015 14:19:35 +0200

On Fri, Apr 17, 2015 at 03:48:59PM -0700, manning wrote:
> I think #3 is ready to proceed.  The other two suggest fundamental 
> changes to the DNS which need more thought.
I disagree. Switching DNS from 0.001% of queries over TCP to 100% is
IMHO a far greater change to DNS then the other proposals. I think
we don't know enough yet to adavance just one proposal.

So long
-Ralf

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 19 Apr 2015 07:38:18 -0700

> we don't know enough yet to adavance just one proposal.

Just to clarify: draft-hzhwm-dprive-start-tls-for-dns does not propose to switch 100% of DNS to TCP. It only proposes switching the traffic between stubs and recursives that agree to the new TCP-based protocol. If a recursive doesn't want to do TLS, it simply doesn't advertise that it is willing to do so, in the same way that in the other proposals, if the recursive doesn't want to encrypt, it simply doesn't advertise that.

--Paul Hoffman

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 20 Apr 2015 02:29:08 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of Ralf
> Weber
> Sent: Sunday, April 19, 2015 5:50 PM
> To: manning
> Cc: [email-masked]; Warren Kumari
> Subject: Re: [dns-privacy] Call for Adoptions on the 3 documents.
> 
> I disagree. Switching DNS from 0.001% of queries over TCP to 100% is IMHO a
> far greater change to DNS then the other proposals. I think we don't know
> enough yet to adavance just one proposal.

We had proposed DNS over DTLS (DNSoD) http://tools.ietf.org/html/draft-wing-dnsop-dnsodtls-01 sometime back; If there is interest in the WG we can re-publish the draft in the WG for further discussion.

-Tiru

---

From: Ralf Weber <[email-masked]>
Date: Mon, 20 Apr 2015 12:43:04 +0100

On Sun, Apr 19, 2015 at 07:38:18AM -0700, Paul Hoffman wrote:
> [BJust to clarify: draft-hzhwm-dprive-start-tls-for-dns does not
> propose to switch 100% of DNS to TCP.  It only proposes switching the
> traffic between stubs and recursives that agree to the new TCP-based
> protocol. 
Even that at scale changes considerably how DNS works. Let's consider a
DNS server that handles 10000 qps, which almost every server today
should be capable of. At major ISPa we see on average around 0.1
queries per subscriber per second, so this single server will handle
100000 subsribers and this means it will have 100000 open TCP
connections. And that is only if the connections are coming from the
home gateway. Now consider that they are coming from the end devices. I
have three kids who each have a laptop and and smartphone. I also have
an AppleTV and a central server that serves video, music, etc. That is
10 devices, so we are now talking about 1 million connections to that
DNS resolver. And then there are resolver that can do a lot more
queries per second. 

>  If a recursive doesn't want to do TLS, it simply doesn't
> advertise that it is willing to do so, in the same way that in the
> other proposals, if the recursive doesn't want to encrypt, it simply
> doesn't advertise that.
Why are we doing it than? If we don't assume that everybody will use
it for our scaling of the protocol then we are doing something wrong
IMHO. I fear that if we design something that has a large deployment
cost we will not get it deployed.

So long
-Ralf

---

From: 神明達哉 <[email-masked]>
Date: Mon, 20 Apr 2015 10:08:10 -0700

At Wed, 15 Apr 2015 09:08:44 -0400,

> http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

I'd like DPRIVE to adopt #2 and #3.  I don't think DRIVE has to adopt
#1.

I think #3 is the most promising approach in terms of deployability.
Using TLS for this purpose may not look elegant, but on the other hand
we have a lot of experience with it and development tools to make the
implementation efforts less difficult.  I also don't believe in
clean slate approaches, especially for anything related to legacy
technologies such as DNS.  While it's true that we'll need to modify
both the server and client in a non-trivial manner, I believe we
shouldn't underestimate the deployment cost of clean slate approaches.

The biggest obvious concern with the TLS approach is that it doesn't
work for UDP.  I agree that this has to be able to be usable by
default in a very busy environment such as a large ISP that provides
millions of subscribers with a recursive DNS service.  We'll need more
analysis and experiments, and the latter should be conducted for more
harsh environments than a research network.  I hope these data points
will be provided as we discuss protocol details in this wg, and,
hopefully, the result will be acceptable.

But it's also possible that it turns out that we cannot just rely on
TCP in the end.  So I think we'll need to discuss at least one other
approach that allows the use of UDP, i.e, #1 or #2.  I don't have a
strong preference between these two, but #1 seems to me rather ad hoc
while it's essentially closer to a clean slate approach (it seems to
me a totally new protocol except that it still uses DNS message
formats).  If our conclusion is that we need something really new, I'd
keep the DNS protocol less messy.  (There might be other approaches
that allow the use of UDP, but I'm assuming we don't go back to
exploring those other solutions at this stage).

--
JINMEI, Tatuya

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2015 11:13:01 -0400

[ Top-post ]

A reminder to please send over views.
We'd really really like a bunch more feedback - we have had many
discussions, and I *know* folk have views -- please express them!

W

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 21 Apr 2015 14:05:49 -0400

There are two sets of issues:

1) Discovery
2) Presentation

I suggest dividing the drafts into two parts and considering these
separately. DNS currently has two transports. The idea that all uses
can be addressed over TCP is currently unproven as far as the majority
of the stakeholders whose action is required for deployment.

Discovery
========

Confidential DNS and TLS for DNS both handle the discovery portion as
an upgrade from regular DNS protocol. This is directly analogous to
the STARTTLS approach introduced in SMTP. As such it has the advantage
of being expeditious and the weakness of being vulnerable to a
downgrade attack.

While there are approaches that can be taken to prevent a downgrade
attack, these have not matured for STARTTLS/SMTP and it is difficult
to see how to apply DNSSEC in this particular case since the starting
point for discovery is an IP address, not a domain name.

It is clear that 'some mechanism' of this sort is required and the one
presented in TLS for DNS is probably as good as can be done in that
situation.

Private DNS takes the approach of introducing a new protocol for Web
Service binding that leverages TLS to establish an authenticated
session key for a Web service specified by DNS name (i.e.
'google.com', not '8.8.8.8'). This approach is designed to address the
use case where a device establishes a 'lifetime binding' with a
particular DNS service for resolution services. Optionally, a binding
may be for a subset of the DNS namespace.

This proposal is a very general Web Service Discovery mechanism
designed to support multiple protocols. The idea being that when a
device is first initialized, it is bound to a collection of services
that it will need. For an embedded device this would be likely {DNS,
ACME, SMTP, Log}, for a user it would likely be {SMTP, XMPP, IMAP,
DNS, OpenID...}

The two schemes adopt different deployment strategies. DNS over TLS
attempts to reduce the size of the ask to the bare minimum. Private
DNS attempts to maximize the Reward while keeping the cost bounded.

Proposal:

* Adopt the Discovery portion of TLS for DNS now with the proviso that
the in-band upgrade mechanism be demonstrated to support additional
presentation transports and establish a registry for declaring such
transports in the usual way.

* Get a fast win with the above approach if possible, while exploring
Discovery mechanism of Private DNS on an experimental basis.

Presentation
==========

DNS over TLS proposes reuse of the existing TLS stack. This has the
advantage of simplicity if a device already has a TLS stack. Otherwise
it is a vast increase in complexity. The main drawback to TLS is the
need for TCP transport. This is an approach many of us remain
skeptical of. And even if the argument can be won inside the group
there is little evidence that it would be accepted outside.

There are several parties that have the technical resources and
infrastructure who could simply roll out TLS over DNS today if they
were convinced of the benefits. With SPDY we had a vendor come to us
with a fait acompli.

Private DNS proposes a simple mechanism currently based on a
pre-established symmetric key and ticket. But the plan was to drop the
CFRG ECC key in as soon as it became available.

Proposal: Adopt the relevant part of DNS over TLS as the TCP based
scheme and Private DNS as the UDP scheme.

Separating the protocol into layers is work but it is the right
approach I believe.

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 21 Apr 2015 16:47:38 -0400

> On Apr 15, 2015, at 9:08 AM, Warren Kumari <[email-masked]> wrote:
> 
> Hi all,
> 

I like #3 with the caveat that support for DTLS is added for UDP. I think having a dedicated port (already included in the draft) for TLS/DTLS is beneficial to speed up the initial connection. A STARTTLS mechanism is necessary but hopefully will become less used over time. The benefit of this approach is that it happens apart from the DNS query/response code that does not need to change. Another advantage is that TLS security can improve over time apart from DNS but DNS can gain the benefits without having to roll out new DNS code, only the TLS libraries that are used by multiple protocols (HTTPS, IMAPS, etc).

Thanks,
Tom

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 22 Apr 2015 14:52:02 +0200

On Wed, Apr 15, 2015 at 09:08:44AM -0400,
 Warren Kumari <[email-masked]> wrote 

> http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

I think it should be adopted because:

* It provides confidentiality through encryption.
* It may provides authentication (even if it is not detailed
  currently).
* It relies on a well-known, widely implemented protocol. TLS has
  weaknesses but they are known. I suspect that alternative proposals
  have as many weaknesses but they are yet undiscovered.
* It relies on TCP, which is not a problem for me, there are good
  reasons, besides privacy, to do more TCP for the DNS (such as
  reflection attacks) and I think it is realistic (rfc5966bis)

> https://datatracker.ietf.org/doc/draft-wijngaards-dnsop-confidentialdns/

A nice second-choice. The good thing is it uses UDP, which makes one
less change to the DNS. The bad thing is that it is yet another
new protocol and new security protocols tend to have hidden holes.

> 2) Private-DNS: https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/

Frankly, I was never able to master it completely. Insufficient brain
power.

4) DNScrypt

Only one implementation, few users, very little experience, no intent
from its supporters to engage in a dialog.

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 22 Apr 2015 16:19:16 +0200

I support adopting 3) draft-hzhwm-dprive-start-tls-for-dns.  It may not
be in shipping shape, but I think it is a worthy path to pursue and can
be tweaked further along.  In particular, I think it would be a good
idea to consider pushing documents for DNS-over-TCP/TLS and
DNS-over-UDP/DTLS at the same time, with harmonized authentication
language.

Re 1 and 2, I don't understand what advantage they would give compared
to DNS-over-TLS, DNS-over-DTLS, or DNSCurve.  I believe a strong
justification is necessary to motivate adoption.  Frankly, I would
prefer DNSCurve over both 1 and 2.

/Simon

---

From: Watson Ladd <[email-masked]>
Date: Wed, 22 Apr 2015 17:43:17 -0700

I agree that DNSCurve is the best solution. Many of the proponents of
TLS based solution haven't adequately considered how this affects
anycast, DOS resistance, etc. Confidential-DNS can only be fixed by
essentially becoming DNSCurve.

It's clear that deployed, working solutions need to be adopted. When
people say it's easy to implement DNS-over-TCP/TLS, and haven't, I
think that's a warning sign.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Tom Pusateri <[email-masked]>
Date: Wed, 22 Apr 2015 21:01:38 -0400

I didn’t mention this before but since you ask…

I wrote a DNS server from scratch as a DNS Hybrid Proxy (DNS-SD). It was UDP only. I wanted to add TLS support so I first added TCP on the Thursday of IETF in about 7 hours (no meetings I was interested in). Then I added TLS support on top of TCP using OpenSSL in about 1 hour. I used Sarah’s LDNS patches to drill to test it and TLS worked great. I should mention that I’m using libevent. I haven’t done any performance testing yet but I have to say it was very easy to modify an existing UDP-only server. Next, I want to add DTLS. Stewart Cheshire and I have a draft out on DNS Push Notifications that provides pub/sub for DNS. It requires TLS. This was my motivation for making my server work over TLS.

Thanks,
Tom

> On Apr 22, 2015, at 8:43 PM, Watson Ladd <[email-masked]> wrote:
>

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 23 Apr 2015 09:49:32 +0200

> I agree that DNSCurve is the best solution.

I didn't say that.  I believe DNSCurve and DNS-over-(D)TLS are somewhat
different, and which is best depends on what you appreciate.
DNS-over-(D)TLS is to me clearly the best answer for stub resolvers
talking to an iterative resolver, which appears to be the focus of this
WG's charter.

I'll update my position on WG adoption a bit:

I support adopting DNS-over-TLS but urges the WG to adopt DNS-over-DTLS
at the same time, and make consistency between them a requirement.
Having both with different TLS-related security semantics would be a
disaster.  In fact, I would suggest that these two documents are merged
into one.  There is (or, rather, should be) more in common between these
documents than what separates them.

Alternatively, adopt one of them and come to consensus that the other
one should not move forward.

> Many of the proponents of TLS based solution haven't adequately
> considered how this affects anycast, DOS resistance, etc.

By adopting something, hopefully the WG will perform that review.
There seems to be implementation interest.

> Confidential-DNS can only be fixed by essentially becoming DNSCurve.

A variant of DNSCurve that had crypto algorithm agility would be nice.
I don't think Confidential-DNS is there yet though.

> think that's a warning sign.

I wouldn't say it is easy (the complexity of TLS is significant both
from a protocol and implementation point-of-view), however
implementation seems to be in progress.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Apr 2015 12:54:48 +0300

> documents than what separates them.

- Can one resume sessions across protocols (resume UDP session as TCP
  session or vice versa)?
- Does DNS-over-DTLS need some sort of channel identifier in queries
  (taking place of the 5-tuple)? To deal with things like client IP
  address/portrange changes or client socket being dropped[1].
- Also, whereas 53/TCP is surprisingly clean[2], 53/UDP has lots of bad
  stuff going on, sometimes even with packets not destined to the middle-
  boxes.[3][4] How bad is that problem?

Also, some problems with (D)TLS:
- No length hiding: There is no defined mechanism for length hiding
  (which is needed unless one can pad at DNS level). I think there
  have been at least one proposal tho.
- Complexity: Enormously complicated. TLS libraries are almost
  invariably junk for one reason or another.
- Insecure configs: Most of TLS usage is insecure due to usage of
  legacy junk. One could address this by aggressively profiling
  down the usage.

[1] That sort of stuff would kill TCP connection anyway, and TCP
connections are so heavyweight that using resumption is feasible.

[2] Then again, most TCP ports are pretty clean, with only a few
exceptions (I think at most 10 or so).

[3] IIRC, some ISP dropped all outgoing 53/UDP packets with QR bit
[3rd byte MSB] set (and similarly all incoming 53/UDP packets with QR
bit clear). This was to deal with amplification attacks.

[4] Assorted DNS forwarders are infamous for having all sorts of
weird interpretations of DNS (despite the fact that dumb forwarding
based on ID/port would work).

-Ilari

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Apr 2015 10:59:53 +0000

> From: dns-privacy [mailto:[email-masked]] On Behalf Of Ilari
> Liusvaara
> Sent: Thursday, April 23, 2015 3:25 PM
> To: Simon Josefsson
> Cc: Watson Ladd; [email-masked]; Warren Kumari

(D)TLS supports session resumption without server side state https://tools.ietf.org/html/rfc5077 

-Tiru

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 23 Apr 2015 14:11:21 +0300

> (D)TLS supports session resumption without server side state https://tools.ietf.org/html/rfc5077 

It is still 1RTT.

Also, it occurs to me that if there is NAT with non-sticky behaviour
with UDP DNS (UDP DNS might very well be special-cased), things are not
going to work at all without channel identifier (because the ports
change constantly).

Dunno if such middleboxes exist, or if they exist, how common those
are.

-Ilari

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 23 Apr 2015 07:39:16 -0400

> Dunno if such middleboxes exist, or if they exist, how common those

I would think that all the focus on middleboxes in the IETF and the IAB, 
that most middlebox behavior has been identified.

Mark Andrews has done an impressive job document (poor) EDNS compliance
http://users.isc.org/~marka/ts.html - I think such a task around 
middleboxes would be useful

tim

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 23 Apr 2015 12:11:35 +0000

> From: Ilari Liusvaara [mailto:[email-masked]]
> Sent: Thursday, April 23, 2015 4:41 PM
> To: Tirumaleswar Reddy (tireddy)
> Cc: Simon Josefsson; Watson Ladd; [email-masked]; Warren Kumari
> > > From: dns-privacy [mailto:[email-masked]] On Behalf Of
> > > Ilari Liusvaara
> Also, it occurs to me that if there is NAT with non-sticky behaviour with UDP
> DNS (UDP DNS might very well be special-cased), things are not going to work
> at all without channel identifier (because the ports change constantly).

DTLS-SRTP over UDP to secure media is already deployed.

-Tiru

> 
> Dunno if such middleboxes exist, or if they exist, how common those are.
> 
> 
> -Ilari

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Apr 2015 09:46:11 -0400

> I agree that DNSCurve is the best solution.

... which a: was not one of the options, b: is recursive to auth and
c: has not been written up in a draft and brought to the WG.

Please see the threads from October 2014 on DNSCurve (and DNSCrypt),
which included a bunch of information and also:
"Ok, so how about we say that it isn't a solution that we are currently
considering, but if folk fully document dnscurve / dnscrypt in a
draft, and bring it to the IETF / DPRIVE we will might consider it
(and, obviously if it becomes a WG item, change it to meet the our
requirements...)
"

>  Many of the proponents of

Ok, so I'll assume you haven't been following along then.

Please see:
>From the Dallas meeting: 'draft-hzhwm-dprive-start-tls-for-dns: DNS
over TLS" - https://www.ietf.org/proceedings/92/slides/slides-92-dprive-0.pdf
- Slide 6

>From the Hawaii meeting: 'DNS over TCP and TLS
draft-hzhwm-dprive-start-tls-for-dns-00' -
http://www.ietf.org/proceedings/91/slides/slides-91-dprive-5.pdf -
Basically all of it, but mainly slides 21, 22, 23. Page 27 had a demo
of drill talking to unbound...

Also, see http://www.isi.edu/ant/software/tdns/index.html, including digit.

$ tar -xvzf digit-1.4.tar.gz && cd digit && autoreconf --install &&
./configure --without-gnutls && make
$ echo -e 'www.google.com\nwww.yahoo.com\nwww.ietf.org' > names.txt
# StartTLS
$ ./digit -V  -r 185.49.141.38  -f ./names.txt -p 53 -t ssl
# Direct over SSL.
$ ./digit -V  -r 185.49.141.38  -f ./names.txt -p 1021 -t ssl -e

The 185.49.141.38 (and  2a04:b900:0:100::38) test / demo server is
running on the getdns jail, and is run by the getdns team; the getdns
developers can all access and manage it (it was originally set up for
the Bits-n-Bites demo).  NLnet Labs is a collaborator
in the getdns project, and very kindly provides hosting.

The digit code was written as a test / research project, and is useful
for testing -- there are other things like the tdns_cli_proxy (also on
that page) to e.g try using this like a user.
There is also the Sinodun work
(https://portal.sinodun.com/wiki/display/TDNS/DNS-over-TLS+Project+Homepage)
, including a page helpfully called "Try DNS-over-TLS"...

W

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Apr 2015 07:44:51 -0700

> (and, obviously if it becomes a WG item, change it to meet the our

Looking through the archives I see that in October the DNSCrypt people
promised to write and upload a draft. That never happened,
unfortunately.

> of drill talking to unbound...

I agree: we do have an implementation. Thanks for correcting me.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 23 Apr 2015 10:53:51 -0400

> I agree: we do have an implementation. Thanks for correcting me.

No worries, and apologies for the somewhat huffy tone...

W

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 27 Apr 2015 17:15:32 +0200

> - Can one resume sessions across protocols (resume UDP session as TCP

I don't think anyone has implemented something like that.

>   address/portrange changes or client socket being dropped[1].

If I understand correctly, I don't believe DTLS has this, nor that it is
something you want -- if something is messing with the traffic, you
wan't detect/reject it not work around it.

>   boxes.[3][4] How bad is that problem?

I have no idea.  Isn't that part of the problem?

>   have been at least one proposal tho.

(D)TLS has message padding to mitigate packet length analysis.
Addmittedly, you can't pad more than 255 bytes.

>   legacy junk. One could address this by aggressively profiling

Sure, but you could say the same for DNS.  I doubt that we can design a
security protocol better than TLS here though.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 27 Apr 2015 18:44:40 +0300

> wan't detect/reject it not work around it.

This is about dealing with things like:
- ISP suddenly renumbering connection.
- NAT dropping state.

The DTLS itself does not specify how to associate packets with
connection state.

Some of the ways seen: 5-tuples, in-band connection identifiers, out-
of-band designation.

> Addmittedly, you can't pad more than 255 bytes.

Only in block modes, which have number of problems (Chrome actually
warns about "obsolete cryptography" if those are used).

-Ilari

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 30 Apr 2015 14:22:14 -0400

All

The Call for Adoption for these three documents has ended.  I will 
attempt to summarize what appears to be the group consensus:

    TLS for DNS: Initiation and Performance Considerations:
    http://datatracker.ietf.org/doc/draft-hzhwm-dprive-start-tls-for-dns/

This document has rough consensus on moving forward.

     Confidential DNS

There was not enough consensus to adopt this draft. There seemed to be 
significant interest, but at the same time several had commented that 
needs further work.

     Private-DNS
     https://datatracker.ietf.org/doc/draft-hallambaker-privatedns/

There was some interest in this, but not enough to call consensus.

Also, at the last minute, Mr. Wing, et al.,  updated their draft:

     DNS over DTLS (DNSoD)
     https://datatracker.ietf.org/doc/draft-wing-dprive-dnsodtls/

There was some lively discussion on adopting this, or pairing it with 
Confidential DNS.   However, it did not make the initial list, so we 
can't readily adopt it w/out an official call for adoption.   I believe
the chairs feel if the Working Group has spent time studying the draft, 
we could run a Call for Adoption.

This will help us focus for a period of time. It does not mean that the 
working group will stop adopting solution documents. We can, and will 
adopt other drafts in the future.

thanks
tim