Re: [dns-privacy] [DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Martine Sophie Lenders <[e-mail]>]

Hi Ben,

On 23.06.23 22:23, Ben Schwartz wrote:
> I think it would be helpful if this document were more explicit about 
> its motivation.  In my view, the underlying motivation for this draft is 
> to enable seamless management of DNS service within a CoAP-centered 
> deployment, by sharing key distribution, access controls, monitoring, 
> etc.  The draft claims various performance benefits from DoC, but these 
> are unproven and seem unlikely to be significant.

We have a paper on the performance benefits just accepted for CoNEXT, 
which we will cite once it is published. An early pre-print (the final 
paper underwent some major revisions though) is available on arXiv [5].

> ...
> 
>     For our document, I think we
>     need at least confirmation or decline that the "coap" ALPN could be
>     used
>     for DTLS, SVCB for OSCORE/EDHOC, I think is out of scope at the moment
>     anyways.
> 
> I'm not sure I follow, but using the same ALPN for multiple transports 
> renders that ALPN permanently incompatible with SVCB.  I recommend 
> keeping "coap" for TLS/TCP only, and defining a new ALPN ID for CoAP/DTLS.

That makes things clearer for us. In the next version we will word the 
draft in accordance to that: only the "coap" is ALPN for TLS/TCP is 
available at the moment. For DTLS and OSCORE alternative approaches need 
to be created (see [1] and [2] in my original mail) which are, however, 
out of scope of the DoC document, in my opinion.

>     Furthermore, there is still an open question, if DoC can or should be
>     translated at a CoAP-HTTP proxy to DoH. Namely, how the FETCH that DoC
>     uses should be translated into the POST/GET of DoH [3].
> 
> I don't think there is any need to specify this.  A DoC server could act 
> as a forwarder to an upstream using DoH, DoQ, etc. in accordance with 
> the relevant standards, without impacting its compliance as a DoC server.
> 
> However, this does resemble a concern I've previously raised: the draft 
> does not explain why it is necessary to define a new DoC mechanism, 
> rather than simply forwarding RFC 8484 DoH through a CoAP-HTTP proxy.

This question was raised in reaction to your concern, actually. Note, 
that if a proxy is used, the target resource needs to be mentioned in 
the CoAP header, increasing the overall packet size, so a proxy should 
be kept optional. Forwarding DoH through a C-H-proxy would make the 
proxy mandatory. In addition, DoC is greatly benefiting from its usage 
of the CoAP-only FETCH method (see [5]).

The question is more a CoRE question, I think. RFC 8132 does not really 
specify, how FETCH should be translated via a C-H-proxy, so I assume it 
to be use-case dependent. Should the draft specify this for the DoC use 
case, and if yes which method should be used, or should the DoC server 
just act as a recursive resolver, using DoH towards the DNS infrastructure?

Best
Martine

[5] https://arxiv.org/abs/2207.07486