Hi!
Martine Lenders, here, one of the co-authors of the draft.
Indeed, as Carsten already stated: Using OSCORE is one of our main use
cases, using a compressed format for DNS messages is another.
We implemented both DNS over DTLS and DNS over CoAP (DoC), including the
variants DNS over CoAPS and DNS over OSCORE, for our evaluation of DoC
[1]. It shows DNS over OSCORE to be in advantage compared to both DNS
over DTLS or DNS over CoAPS. Yes, compared to DNS over DTLS it adds
complexity, at least upfront, but it can be assumed that CoAP/OSCORE is
already present for the application. This amortizes this disadvantage to
only the construction and parsing of DNS messages. With DNS over DTLS
(assuming we even use transport encryption with CoAP) we still need to
implement the state machine of DNS over DTLS, in addition to DNS message
handling. On the other hand side, we gain additional advantages from the
CoAP feature set when using DoC, such as block-wise transfer and, as
previously discussed, en route caching. The latter would also become
possible in an end-to-end encrypted way with [2]. Some of these
advantages are mentioned in Section 1 of the draft.
For a compressed message format, we plan to provide a separate draft in
the future, in an attempt to keep things simple and to easily make that
content type also usable, e.g., with DoH.
Another use case is the usage of encrypted DNS over Low-Power WANs,
e.g., LoRaWAN. Here, due to the transport encryption with DTLS,
compression to fit the small PDUs and handle the low data rates [3], is
not straightforward. As OSCORE encrypts on the application layer,
however, we are able to compress most of the surrounding metadata away
[4], and purely transport the encrypted payload.
Lastly, another possible use cases, which we did not evaluate in any way
yet, would be an encrypted version of mDNS and thus DNS-SD, utilizing
OSCORE group communication [5]. Multicast encryption is not covered by
either of the other encrypted DNS-over-X solutions so far.
Best regards
Martine
[1] https://arxiv.org/pdf/2207.07486.pdf
[2] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore
[3] https://datatracker.ietf.org/doc/rfc8724
[4] https://datatracker.ietf.org/doc/rfc8824
[5] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm
Am 15.08.22 um 20:09 schrieb Carsten Bormann:
On 15. Aug 2022, at 19:41, Ted Lemon<mel...@fugue.com> wrote:
On Aug 15, 2022, at 1:34 PM, Carsten Bormann<c...@tzi.org> wrote:
On 15. Aug 2022, at 17:11, Ted Lemon<mel...@fugue.com> wrote:
This is a good question. I think we’d want to understand what the actual use
case is for DNS-over-CoAP before proceeding with this,
The main use case is systems that already implement CoAP and do not want to add
machinery for some protocols that are used only for very specific purposes.
You’re going to have to construct a DNS packet. I presume CoAP is using DTLS,
DTLS is one choice, defined in RFC 7252. Newer constrained implementation
often look at OSCORE instead, RFC 8613.
so you have to have DTLS. So again, I don’t see how this reduces complexity. It
seems like it adds complexity.
I haven’t checked this, but I would expect there are enough differences in how
DNSoDTLS uses DTLS that the complexity of getting this right exceeds that of
using CoAP.
I’ll leave that to the authors; obviously, all caches have limitations, but
being able to make use of CoAP caches along the way would be an improvement.
It is not a given that caching with CoAP makes things better. What is CoAP’s
caching behavior? How will it handle short TTLs? Reading the document, it’s
clear this has not been considered.
The -00 version does not have to solve those problems. Slideware does exist
for them...
Given that the whole point of this is to make DNS connections private, I would
assume that the cache shouldn’t have the credentials to peek into the packet.
Except that it must. So I really don’t understand the threat model here.
OSCORE was designed to offer some capabilities in this regard. I’m sure a
future document will include examples for that.
But this is work that best can be done in the working group, between
implementers and experts for the specific protocols and their caching behaviors.
That can definitely be done (for a definition of “compress” — a concise form
for some DNS data might be a better approach), but it to me it seemed working
out the protocol machinery first is the right way to proceed here. (From the
point of view of the CoAP protocol, this would just be a separate media type.)
I don’t think this is true. Just because you can do something doesn’t mean you
should. Until we can come up with some use case for this that solves a problem
that isn’t already solved, I don’t think the IETF should be pursuing this work
at all.
It seems to me you are basing this view on a scan of the individual submission
document.
WG discussions have happened (and many WG members are also cognizant of, e.g.,
CoAP caching behavior), so it is not a surprise that many of use come to a
different conclusion.
Grüße, Carsten
_______________________________________________
core mailing list
c...@ietf.org
https://www.ietf.org/mailman/listinfo/core
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
