Re: [dns-privacy] [DNSOP] Next steps: draft-ietf-core-dns-over-coap

[Ben Schwartz <[e-mail]>]

I think firmware size is a perfectly reasonable and sufficient motivation for this draft, but I don't think it can be described as "performance".

--Ben Schwartz


________________________________
From: Christian Amsüss
Sent: Wednesday, July 5, 2023 12:17 PM
To: Ben Schwartz
Cc: Martine Sophie Lenders; [e-mail]; [e-mail]; dnsop; DNS Privacy Working Group
Subject: Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap

Hello Ben,

picking one of the points in the thread and leaving the rest to another
subthread:

> > 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].
>
> This paper appears to be focused on DNS performance, but DNS is
> usually only a small component of overall system performance.

In this context, I think a relevant performance metric is firmware size
(or, equivalently, network load from firmware updates) -- a metric that
is covered in the latest preprint[1] of the same work. While a CoAP plus
OSCORE stack is marginally larger in firmware that a DNS plus DTLS stack
(and admittedly that's not even accounting for EDHOC that'd also be
needed if the DNS server is authenticated with public key cryptography),
that is text the application already pulls in, whereas the DTLS
component of DNS over DTLS alone already weighs another 20KiB of
firmware size. That represents a significant portion of the flash memory
available on the relevant microcontrollers.

Software complexity (both in terms of LoC and in terms of items on an
SBOM) is a factor that improves in parallel to the binary size savings.

BR
Christian

[1]: https://arxiv.org/abs/2207.07486v2

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom