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
On Thu, Jun 30, 2022 at 4:51 PM Tommy Pauly <tpauly=40apple.com@xxxxxxxxxxxxxx> wrote:
Thanks again for the review, Martin!--For those following along by email, we’ve resolved these comments through these two PRs:Thanks,TommyOn Jun 26, 2022, at 7:09 PM, Martin Thomson <mt@xxxxxxxxxxxxxx> wrote: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/66
I'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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
