Hi,
There are a few Enterprise use-cases requiring the need for DoH Identity/Authentication. 1. Enterprise DNS Security (DNS Filtering). In this scenario, a DoH identity is needed so as to enforce the right Enterprise Policy for that device/user. Additionally, any reporting or remediation requires a way to pivot back to the device & user to take corrective action. Their could be two levels of identity (one that gets you a policy, but keeps individual identity private - and one that binds directly to a user & device) 2. Enterprise Private DNS is accessible from anywhere via an Auth-DoH <https://blogs.cisco.com/security/future-focused-a-safer-way-to-expose-priva te-server-names> connection. This allows for Enterprise Private Access to be possible without the need for additional DNS for external proxy / vpn use cases. 3. Additionally, I believe some ad-blocking services and other DoH-based service-offerings are in need of a DoH identity/authentication to apply policies as well. Ideally, device and user identity/authentication are independent - this is because you might have users with multiple devices or a single device with multiple users. I am aware that today some 3rd party DoH client implementations are using DoH-URI-encoding for an Identity (weak binding). I am also aware of a DoH service that is using mTLS (mutual TLS auth) - (strong binding) to achieve a similar outcome. Those vendors should chime in on their needs as well, if possible. We have had some initial discussions with various vendors on this topic and have come to realize that the proposed approaches are all different. Hopefully we can work together, across vendors, to decide on a common approach to DoH Identity/Authentication so as to avoid fragmentation in this area. Preferably via a method that allows for device and user identity/auth to be independently conveyed. I would appreciate your thoughts/comments on this. -Vinny
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
