| Hi Rob,
This particular item was a matter of significant WG discussion, specifically at the IETF 111 meeting.
Generally, a client will query resolver.arpa upon joining a network.
Obviously, an attacker that can persistently drop SVCB queries for resolver.arpa on a network can prevent clients from automatically upgrading to encrypted DNS. However, there are two relevant cases where repeating the query at some interval is useful:
- The SVCB answer was unintentionally dropped / lost due to a temporary network problem. In such a case, a client that got unlucky when they joined the network can retry later, and may indeed get a valid response. - Some attackers may be able to launch a temporary attack where they can drop or intercept packets, but cannot do so persistently. Clients querying periodically makes the job of the attacker harder, since they need to persistently block these packets.
Beyond that, there are some devices which do stay on single network attachments for a very long time (weeks, months, etc). It is not unreasonable to think that a DNS resolver may start advertising support for a designated resolver while clients are already attached, and this allows those clients to upgrade when available if they re-check periodically.
Thanks, Tommy On Jun 30, 2022, at 5:21 PM, Rob Sayre <sayrer@xxxxxxxxx> wrote:
Hi,
The draft still says
"To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically."
What in the world does that mean?
thanks, Rob
Thanks again for the review, Martin!
For those following along by email, we’ve resolved these comments through these two PRs:
Thanks, Tommy
Hi, I've only loosely followed the progress of this document in the ADD working group. I think that it is a good mechanism and it is clear that a lot of effort has been put in to ensure that it is clear, readable, and comprehensive. However, there is an issue that should block publication until it is resolved. It's a small thing, but there is no requirement that the TLS certificate offered by the designated resolver chains to a trust anchor at the client. I'm guessing that this is just an oversight as I see that implementations are doing the right thing; see https://github.com/ietf-wg-add/draft-ietf-add-ddr/issues/66I've opened another issue regarding modification attacks for "dohpath", but I believe that is down to clarity of text rather than a similar omission. Cheers, Martin On Sat, Jun 25, 2022, at 03:29, The IESG wrote: The IESG has received a request from the Adaptive DNS Discovery WG (add) to
consider the following document: - 'Discovery of Designated Resolvers'
<draft-ietf-add-ddr-07.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2022-07-08. Exceptionally, comments may
be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.
Abstract
This document defines Discovery of Designated Resolvers (DDR), a
mechanism for DNS clients to use DNS records to discover a resolver's
encrypted DNS configuration. This mechanism can be used to move from
unencrypted DNS to encrypted DNS when only the IP address of a
resolver is known. This mechanism is designed to be limited to cases
where unencrypted resolvers and their designated resolvers are
operated by the same entity or cooperating entities. It can also be
used to discover support for encrypted DNS protocols when the name of
an encrypted resolver is known.
The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-add-ddr/
This document also relies on
https://datatracker.ietf.org/doc/draft-ietf-add-svcb-dns/ and the ADD
WG has another document
https://datatracker.ietf.org/doc/draft-ietf-add-dnr/, which should
probably be reviewed at the same time.
No IPR declarations have been submitted directly on this I-D.
--
Add mailing list
Add@xxxxxxxx
https://www.ietf.org/mailman/listinfo/add
-- last-call mailing list last-call@xxxxxxxxhttps://www.ietf.org/mailman/listinfo/last-call
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
|
