Hi Rob,
That material used to be in the core text of DNR, then moved to appendix, and finally to a separate document (draft-boucadair-add-deployment-considerations)
as per the WG request. We also used to have a reference to it, but that citation was removed in -04 to follow what the authors heard from the WG.
A call for adoption was issued for that document, but the conclusion was that “the material in the draft goes beyond the ADD charter”. See more at
https://mailarchive.ietf.org/arch/msg/add/2rSoz8pr8KkEPWkYT8NhZUWWMi0/
Please note that for the cellular case, the provisioning is likely to happen using dedicated PCO IEs. At last for DNR, including cellular specific security
considerations such as those in
https://datatracker.ietf.org/doc/html/rfc6459#section-9 is really not justified.
Thanks.
Cheers,
Med
De : Rob Sayre <sayrer@xxxxxxxxx>
Envoyé : mardi 28 juin 2022 02:04
À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>
Cc : Martin Thomson <mt@xxxxxxxxxxxxxx>; ADD Mailing list <add@xxxxxxxx>; last-call@xxxxxxxx
Objet : Re: [Last-Call] [Add] Last Call: <draft-ietf-add-ddr-07.txt> (Discovery of Designated Resolvers) to Proposed Standard
Hi,
I guess that answer raises a few more questions. What document were they moved to? Shouldn't there be a reference to it? Also, while the DHCP/RA Guard advice seems relevant where applicable, isn't that advice also deployment specific?
My concern here is that the Security Considerations don't cover some very common use cases (like mobile phones), and also don't highlight that issue. I also question the "clients can re-send their SVCB queries periodically" text in the
DDR document--I'm not sure what the threat model is there.
Hi Rob,
We used to have some cellular considerations in DNR but the WG considered these aspects as deployment specific and agreed to
move them into a separate doc.
Cheers,
Med
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.
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
_________________________________________________________________________________________________________________________
Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.
|
