[Add] Current add drafts

[Ralf Weber <[e-mail]>]

Moin!

So in preparation for the add wg meeting I read all the documents that 
are add related as per data tracker and some others. And while I gave 
some feedback to some directly I took a step back and categorised them 
for me and want to share that with you, maybe using this to find some 
common ground or a way forward.

1. The first category is “informational drafts”:
These are drafts that look or describe the status quo of the problem 
space or at least some aspects of it. The drafts in this scenario are:
- draft-campling-operator-observations
- draft-deen-add-threats
- draft-mglt-add-signaling-filtering-policies

2. The second category is “use existing network technologies to 
upgrade to a secure transport”:
These drafts are using existing network technologies like DHCP or RA 
(and a lot more) to convey a secure transport to a client. I was amazed 
by the depth and width of the technologies covered in these drafts. They 
are:
- draft-btw-add-home
- draft-btw-add-ipsecme-ike
- draft-btw-add-rfc8484-clarification
- draft-reddy-add-enterprise
- draft-reddy-add-iot-byod-bootstrap
- draft-reddy-add-server-policy-selection

3. The third category is “just put it in the DNS”:
These drafts use the DNS as direct as possible to get you to a secure 
transport. These drafts are:
- draft-cook-doh-discovery-trial
- draft-pp-add-resinfo
- draft-pp-add-stub-upgrade
- draft-rescorla-doh-cdisco

4. The fourth category is “create another layer(s) to solve the 
problem”:
These drafts use DNS or HTTPs, or both to create one or more additional 
layers to discover “resolvers”. These drafts are:
- draft-mglt-add-rdp
- draft-pauly-add-resolver-discovery
- draft-schinazi-httpbis-doh-preference-hints

This of course is how I see the drafts and is a very rough 
categorisation and some aspects of some drafts might fall into other 
categories, but I am happy to discuss this. However coming from this 
categorisation my view on working group work is like this:

Category one is needed, but is very controversial as we already seen, so 
it will take a long time to come with something that everybody can agree 
on. Category two looks like a desirable end goal for me as it is the 
right place for the network to do stuff, but given that it is very 
complex and broad and requires interactions with other groups so it 
might take some time to finalise it, but it should be at least our 
medium term goal. Also as most of category two is really in the lower 
levels of an operating system it might be hard for an application to get 
the rights from the OS to do these things. Which is were category three 
comes in that I see a good short term solution to get users to secure 
transport as the barriers for applications and providers of DNS services 
are very low. I’m struggling with category 4 as it creates another 
distributed overlay over an already distributed DNS system. I can 
understand the need to make a direct DNS connection from the end user to 
the content, but if you want to do this an IMHO better solution would be 
to put the recursive resolver in the end user device and work with 
dprive to secure the recursive to authoritative DNS connections.

So long
-Ralf
—--
Ralf Weber