Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)

[[e-mail]]

Paul,

(focusing on this specific part as many of your comments are related to the intended scope)

> If the document said "These are the new DHCP / DNR options, how or
> if the client uses them is out of scope", then I would agree.

The document focuses on discovery, not selection. That's why the normative behavior in the draft is drawn from the perspective of **DHCP clients/RA receiving hosts ** not ** DNS clients". In particular, Section 3.3 does not include any normative language. That section is provided for convenience to describe a typical usage.

Cheers,
Med

> -----Message d'origine-----
> De : Paul Wouters <[e-mail]>
> Envoyé : samedi 16 juillet 2022 16:31
> À : tirumal reddy <[e-mail]>
> Cc : Paul Wouters <[e-mail]>; The IESG
> <[e-mail]>; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Objet : Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11:
> (with DISCUSS)
> 
> On Fri, 15 Jul 2022, tirumal reddy wrote:
> 
> > The policy of a client to select the discovered network-
> signalled
> > encrypted resolver is out of scope of the ADD WG charter. The
> client
> > may have a policy to select the discovered resolver only if it
> has
> > sufficient reputation (e.g.,  Comcast provided encrypted
> resolver
> > added to the TRR of Firefox,
> > seehttps://blog.mozilla.org/products/firefox/firefox-
> news/comcasts-xfi
> > nity-internet-service-joins-firefoxs-trusted-recursive-resolver-
> progra
> > m /). In deployments like home/mobile networks offering network
> > security services, Enterprise networks allowing the use of BYOD
> > (without
> > MDM) can only rely on DNR/DDR to signal the network-designated
> > encrypted resolver. The end-user may opt to use the network-
> signalled
> > encrypted resolver in trusted networks and use an external
> resolver in
> > untrusted networks. Further, DNR prevents on-path attack and
> pervasive monitoring of DNS messages in the local network
> by allowing local DNS to upgrade from plaintext to encrypted. In
> addition, it helps UX by using DNS names for the DNS servers
> (rather than IP addresses).
> 
> While the client policy is out of scope, the draft does mention
> different types of connections possible to encrypted DNS
> Resolvers, eg authenticated or opportunistic. It also offers
> advise on how clients respond when they can or cannot verify the
> TLS connection to the Encrypted DNS Resolver. So, it appears to be
> partially in and out of scope.
> 
> If the document said "These are the new DHCP / DNR options, how or
> if the client uses them is out of scope", then I would agree. But
> the document is more along the lines of "These are the new DHCP /
> DNR options, these options might be useful or less useful to the
> client, which can try these things to validate the encrypted DNS
> server and act differently based on the outcome". But without the
> required operational and security considerations.


_________________________________________________________________________________________________________________________

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.