Hi,
I was also surprised to see no mention of cellular networks in the Security Considerations. Did I miss something? This is a little different from voluntarily joining a WiFi network.
It doesn't come up in https://datatracker.ietf.org/doc/draft-ietf-add-ddr/ or https://datatracker.ietf.org/doc/draft-ietf-add-dnr/, as far as I can tell. I don't know whether the WG considered this issue.
thanks,
Rob
On Sun, 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
