On 6/28/23, 10:24 AM, "Martine Sophie Lenders" <m.lend...@fu-berlin.de> 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
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
