[Iotops] Re: Encrypted DNS and draft-mishra-iotops-iot-dns-guidelines

["Tschofenig, Hannes" <[e-mail]>]

One other point: I think it would be helpful to describe the specific privacy threat you are concerned about in the draft. From the discussion so far, it seems the main issue is that an entity on the communication path between the IoT device and the ISP can observe the DNS queries being made. You appear to assume that the ISP is trustworthy, since the device is using its DNS resolver. Is that correct?

You are also assuming that the combination of the source IP address and the DNS query itself reveals meaningful information to an observer. But in many cases, especially with constrained IoT devices, there is very little variability in network behavior. These devices typically connect to only a small number of servers, often just their device management server.

Ciao
Hannes

Von: Tschofenig, Hannes <[e-mail]>
Gesendet: Montag, 28. Juli 2025 13:44
An: Abhishek Mishra <[e-mail]>
Cc: Jim Mozley <jmozley=[e-mail]>; [e-mail]
Betreff: [Iotops] Re: Encrypted DNS and draft-mishra-iotops-iot-dns-guidelines

Hi Abhishek,

I believe you also need to add an applicability statement because your research has focused on smart home devices where you believe that privacy is impacted using plaintext DNS. While I personally do not believe that this is the most important privacy concern in a smart home environment, I can follow the logic of your research.

A large part of IoT usage is, however, in industrial IoT and there the notion of personal data is not applicable. It would be important to point this out.

Ciao
Hannes

Von: Abhishek Mishra <[e-mail]<mailto:[e-mail]>>
Gesendet: Freitag, 25. Juli 2025 11:51
An: Tschofenig, Hannes <[e-mail]<mailto:[e-mail]>>
Cc: Jim Mozley <jmozley=[e-mail]<mailto:jmozley=[e-mail]>>; [e-mail]<mailto:[e-mail]>
Betreff: Re: [Iotops] Re: Encrypted DNS and draft-mishra-iotops-iot-dns-guidelines

Hi Hannes,

Thank you for your thoughtful comments and for raising important points during the IOTOPS WG session. To follow up:

Clarifying the Goals of the BCP:
The primary goal of this BCP is to provide operational guidance to IoT device manufacturers and network operators regarding DNS usage in IoT environments. This includes surfacing known misconfigurations, highlighting security and privacy risks, and recommending practices that improve resilience and interoperability. We are not proposing/altering any new or existing protocols, but rather encouraging adoption of existing standards (e.g., DoT, DoH, DNSSEC, etc.) in a way that is feasible/necessary for current IoT deployments.

On Privacy Threats and Their Scope:
You rightly point out that encrypted DNS in isolation does not fully prevent user or device tracking. We agree, and the draft currently focuses on mitigating passive network observation and spoofing at the DNS layer. Device fingerprinting through behavioral patterns, TLS metadata (e.g., unencrypted SNI), or other channels remains a broader and more complex problem. We intend to clarify that the privacy goals here are narrowly scoped to DNS query confidentiality and integrity. We are aware of padding as a possible mitigation through our prior research which Martine also pointed out and have discussed that in the draft.
We will also take your suggestion to refer to RFC 6973 for privacy terminology explicitly.

DNS Attacks in TLS-Protected Contexts:
Your point about reassessing the practical threat model for DNS in TLS-protected IoT communications is well taken. We believe DNS remains a relevant attack vector because:
i) DNS resolution often precedes the establishment of encrypted channels.
ii) Manipulated or spoofed DNS responses can redirect IoT devices to malicious endpoints before a secure session begins at startup only.
iii) Weak or misconfigured DNS resolvers can expose sensitive operational metadata.
That said, we agree this needs to be better contextualized in the draft BCP.

Thanks again for your input – we’ll work on incorporating these clarifications.

Best regards,
 Abhishek

________________________________
From: "Jim Mozley" <jmozley=[e-mail]<mailto:jmozley=[e-mail]>>
To: "Hannes Tschofenig" <[e-mail]<mailto:[e-mail]>>, [e-mail]<mailto:[e-mail]>
Sent: Friday, 25 July, 2025 10:41:37
Subject: [Iotops] Re: Encrypted DNS and draft-mishra-iotops-iot-dns-guidelines
On 24/07/2025, 13:59, "Hannes Tschofenig" <[e-mail]<mailto:[e-mail]>> wrote:
Hi all,

I would like to follow up on the discussion from the IETF IOTOPS WG
meeting regarding draft-mishra-iotops-iot-dns-guidelines and the role of
encrypted DNS in IoT deployments.

[JM] Thanks for taking the time to follow up 😊

As I mentioned at the microphone, we need to be more precise about the
privacy properties we aim to achieve. There is a good IAB document (IETF
RFC 6973) that defines terminology, which could be re-used.
Encrypted DNS alone offers limited protection if the TLS Client Hello
remains unencrypted since the SNI still reveals the target server. This
is especially relevant if the goal is to conceal the FQDN the IoT device
is attempting to connect to.

[JM] The IoT device would be contacting the network resolver over DoT/Q/H to resolve the FQDN rather than the contacting the FQDN itself. The device would use whatever protocol it normally uses to communicate with the FQDN once it acquires an IP address. So if it used ECH it could do so, assuming the target device supported it. As a BCP the draft is not changing anything in protocol terms. I hope I understood your comment above in replying.

After checking, I noticed that WolfSSL already supports Encrypted Client
Hello. Congrats to them!
That said, even the combination of Encrypted DNS and Encrypted Client
Hello may not be sufficient to prevent device fingerprinting, depending
on how the fingerprinting is performed.

[JM] Some of the devices tested by the research team could be identified by the frequency and DNS qnames, using DoT/Q/H would encrypt the qnames when communicating with the resolver.

The point raised during the meeting that a "toaster" can be linked to a
household is valid. However, an ISP can already associate devices to
households based on IP addresses, independently of DNS. Whether such
information is actually useful in practice remains an open question.

[JM] Any communication across the ISP network to a specific IP could be associated with whatever services are known to be running on that IP and hence associated with the household. This BCP does not change that. We should clarify the scope of privacy in the BCP.

A valuable discussion point would be whether, and under what conditions,
attacks on DNS constitute a real threat to IoT devices, especially when
their communication channels are protected by TLS, DTLS, or similar
protocols.
Finally, I would be interested in exploring how the work in the DANCE
working group might relate to this draft.

[JM] We haven’t considered DANCE during development of the draft. We do want to add more on discovery of network-designated resolvers (DNR) RFC9463 related to the devices finding encrypted DNS servers.

Once again thanks for your time in providing feedback.

Cheers, Jim


--
Iotops mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>