Before you go down the mDNS-over-constrained-networks rabbit hole, you might
want
to look at existing practice. E.g. Thread uses SRP (draft-ietf-dnssd-srp, in
last
call) for service registration, and then uses regular DNS and DNS Push for
lookups.
mDNS is used on the infrastructure link (e.g. WiFi) because it's ubiquitous and
permissionless, although it would be nice to get to where we could use DNS Push
there as well. The primary argument against mDNS for constrained networks and
devices is that it winds up delivering a lot of badput: nearly every mDNS
packet is
useless for nearly every recipient. This isn't a problem for unconstrained
networks
and unconstrained devices, but you don't want a battery operated device to have
to
turn on its receiver and look at every service discovery packet, and possibly
have
to forward it, when nearly all of them are not going to be of interest.
I think your main value-add here is compactness. Your argument for OSCORE sounds
convincing, but I'd like to see some practical application of this. If you are
thinking about how to do compression, why wait to write that draft? To me it
seems
like a pretty clear sine qua non for the draft you're trying to work on first.
To
put this in perspective, in the Thread work we've definitely considered ways to
compress DNS packets. We haven't done it, because it's not strictly necessary,
but
this would certainly be an attractive thing to consider. Whereas the other stuff
you are doing here would not be at all compelling. We wouldn't be interested in
this caching mechanism, for example. Message privacy isn't very interesting,
since
our primary use for DNS is DNS service discovery, and our secondary use is
basically also service discovery—finding the IP address of a cloud service with
a
known name. The compelling use case for DoH is the ability to make HTTPS and DNS
lookups share fate; there's no similar compelling use case here. The privacy
benefit of DoH wouldn't apply on a Thread network—you're hiding things that are
easily discovered, and snooping is expensive, so constrained devices aren't
likely
to do it.
There may be a privacy story here, but I think if there is it needs to be
articulated, and not just assumed.
On Thu, Aug 18, 2022 at 3:40 AM Martine Sophie Lenders <[email protected]>
wrote:
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 <[email protected]> wrote:
On Aug 15, 2022, at 1:34 PM, Carsten Bormann <[email protected]> wrote:
On 15. Aug 2022, at 17:11, Ted Lemon <[email protected]> wrote:
This is a good question. I think we’d want to understand what the actual use
case i
s for DNS-over-CoAP before proceeding with this,
The main use case is systems that already implement CoAP and do not want to add
mac
hinery 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 lo
ok at OSCORE instead, RFC 8613.
so you have to have DTLS. So again, I don’t see how this reduces complexity. It
see
ms like it adds complexity.
I haven’t checked this, but I would expect there are enough differences in how
DNSo
DTLS 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 a
ble 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
cachin
g behavior? How will it handle short TTLs? Reading the document, it’s clear
this ha
s not been considered.
The -00 version does not have to solve those problems. Slideware does exist
for th
em...
Given that the whole point of this is to make DNS connections private, I would
assu
me that the cache shouldn’t have the credentials to peek into the packet.
Except th
at 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 d
ocument will include examples for that.
But this is work that best can be done in the working group, between
implementers a
nd experts for the specific protocols and their caching behaviors.
That can definitely be done (for a definition of “compress” — a concise form
for so
me DNS data might be a better approach), but it to me it seemed working out the
pro
tocol 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
shou
ld. 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
docu
ment.
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 co
nclusion.
Grüße, Carsten
_______________________________________________
core mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/core
