Re: [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

[Matthias Waehlisch <[e-mail]>]

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 <[e-mail]>
> 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 <[e-mail]> wrote:
> 
> On Aug 15, 2022, at 1:34 PM, Carsten Bormann <[e-mail]> wrote:
> 
> On 15. Aug 2022, at 17:11, Ted Lemon <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> 
> 
> 
> 


-- 
Matthias Waehlisch
.  Freie Universitaet Berlin, Computer Science
.. http://www.cs.fu-berlin.de/~waehl