Hi Ted,
sorry for the late reply!
re scenarios: during bootstrappign, a constrained requires CoAP and
DNS client capablities. for example, when an LwM2M client registers at a
LwM2M server, which acts as a partial CoAP Resource Directory.
re: your statement "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."
i don't see why an attacker necessarily needs to use a constrained
device.
can you elaborate on who is "we" in your arugmentation?
thanks
matthias
On Thu, 18 Aug 2022, Ted Lemon wrote:
> 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
> <m.lend...@fu-berlin.de>
> 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 <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 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
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core
>
>
>
>
--
Matthias Waehlisch
. Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
