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
OpenPGP_0xD3555B9E03C098C7.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
