On Mon, 27 Jun 2022 at 07:40, 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
Relying on WebPKI is the right thing for general-purpose endpoints but for IoT devices using secure bootstrapping (e.g., BRSKI) could be provisioned with a explicit trust anchor database allowing the use of it to validate the DNS server certificate. We may want to discuss if DNR/DDR or some other secure way of discovering the network-designated encrypted resolver can be used for such IoT devices.
But it is a separate discussion and shouldn't impact the progress of these drafts.
-Tiru
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
--
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
