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

[Ben Schwartz <[e-mail]>]

On 6/28/23, 10:24 AM, "Martine Sophie Lenders" <[e-mail]> wrote:
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].

This paper appears to be focused on DNS performance, but DNS is usually only a small component of overall system performance.

BTW, this reminds me that referring to OSCORE as “end-to-end” in this context is confusing, since the logical “endpoints” are the stub resolver and the authoritative nameserver.

> ...
>
>     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.

That’s fine with me.

>     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]).

I think this explanation should be included in the draft.

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?

The DNS protocol is role-independent, so a DoC server could (in principle) be a recursive resolver, a forwarder, or an authoritative nameserver.  If it is a forwarder, it could use DoH, DoC, or any other transport of its choice to reach its upstream resolver.

Best
Martine

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