Subject: [dns-privacy] DoH Identity / Authentication...

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 26 Oct 2021 16:09:58 +0000

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

---

From: Alec Muffett <[email-masked]>
Date: Tue, 26 Oct 2021 17:16:39 +0100

On Tue, 26 Oct 2021, 17:10 Vinny Parla (vparla), <vparla=
[email-masked]> wrote:

> I would appreciate your thoughts/comments on this…
>

It sounds sensible to me.

Please just make it usable via standard "curl" and/or amenable to standard
web load-balancing.

Or simply ratify Auth/Basic and go from there?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Authentication

-a

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 26 Oct 2021 16:22:39 +0000

Hi,

Thanks for the feedback.  
I think one of the issues here is that DNS (at the OS Resolver) level is headless, meaning there may not be an interactive user logged into the device – however the DoH connection would still need to have some type of identity/auth for those use cases. mTLS can work for this – but the PKI headache for customers might be a barrier.

I would prefer to use WebAuthN – but again that is an interactive-auth as there is no facility in WebAuthN for doing Device-level identity assertions today (headless) independent from the user identity.

-Vinny

From: Alec Muffett <[email-masked]> 
Sent: Tuesday, October 26, 2021 12:17 PM
To: Vinny Parla (vparla) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] DoH Identity / Authentication...

On Tue, 26 Oct 2021, 17:10 Vinny Parla (vparla), <vparla=[email-masked] <mailto:[email-masked]> > wrote:

Please just make it usable via standard "curl" and/or amenable to standard web load-balancing.

-a

---

From: Alec Muffett <[email-masked]>
Date: Tue, 26 Oct 2021 17:35:16 +0100

On Tue, 26 Oct 2021, 17:22 Vinny Parla (vparla), <[email-masked]> wrote:

> Hi,
>
> Thanks for the feedback.
> I think one of the issues here is that DNS (at the OS Resolver) level is
> headless, meaning there may not be an interactive user logged into the
> device – however the DoH connection would still need to have some type of
> identity/auth for those use cases.
>

Historically there exist any number of static URL authentication hacks for
this scenario - and we can be absolutely sure that a DoH connection
requires a URL - from the mildly deprecated:

http://user:[email-masked]/resolve

...syntax, to the marginally more modern use of GET parameters to pass a
token of some sort, on the URL.

Of course there are downsides to adopting such mechanisms, but I presume we
are talking about a niche edge case where the client stack exclusively
supports a URL, and it would be nice for such a mechanism to reuse and be
compliant with the existing H of DoH, rather than reinventing something
wholly new for the D of DoH.

-a

mTLS can work for this – but the PKI headache for customers might be a
> barrier.
>
>
> I would prefer to use WebAuthN – but again that is an interactive-auth as
> there is no facility in WebAuthN for doing Device-level identity assertions
> today (headless) independent from the user identity.
>
>
>
> -Vinny
>
>
>
> *From:* Alec Muffett <[email-masked]>
> *Sent:* Tuesday, October 26, 2021 12:17 PM
> *To:* Vinny Parla (vparla) <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [dns-privacy] DoH Identity / Authentication...
>
>
>
>
>

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 26 Oct 2021 18:49:47 +0200

> On Oct 26, 2021, at 6:16 PM, Alec Muffett <[email-masked]> wrote:
> 
> 
> 
> On Tue, 26 Oct 2021, 17:10 Vinny Parla (vparla), <vparla=[email-masked]> wrote:

I had initially been thinking that it would be good to support both web Auth and mutual TLS, but the more I talk with people about it, the more it looks like we should just do TLS.  So in the absence of a really compelling argument for supporting both, along with all of the future overhead it entails, my current position is mutual TLS only.

                                -Bill

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Tue, 26 Oct 2021 16:59:38 +0000

Hi Bill,

One of the issues with mTLS is the PKI burden on customers. There also is not a good way to convey both device and user  in mTLS (e.g. you can't have independent authentications of user and device within the single mTLS exchange).  Most of the customers we have spoken with have a preference to have both.

-Vinny

-----Original Message-----
From: Bill Woodcock <[email-masked]> 
Sent: Tuesday, October 26, 2021 12:50 PM
To: Alec Muffett <[email-masked]>
Cc: Vinny Parla (vparla) <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] DoH Identity / Authentication...

                                -Bill

---

From: Eric Orth <[email-masked]>
Date: Tue, 26 Oct 2021 13:24:31 -0400

A client-side perspective:

For Chrome browser, we have deliberately avoided any sort of support for
client/device/user identity in DoH.  E.g., Chrome's normal support for mTLS
is completely disallowed through Chrome DoH, and even simple stuff like
cookies is disallowed (Chrome never sends or saves cookies for DoH
connections).  This is primarily due to privacy concerns.  We didn't want
DoH to lead to an increase in user trackability through DNS.

It's pretty clear that there are usecases, especially for enterprise,
where this sort of stuff would be very desirable, but we have so far held
to the policy that OS's are better positioned than browsers to tell when
it's a good idea and desired by the user/admin vs a privacy vulnerability.
So unless we come up with some solution to resolve privacy concerns, Chrome
browser will not likely directly support any of this work, but I think
there's still a big role for this technology in other clients and I think
DPRIVE is a good place for it to be discussed.

On Tue, Oct 26, 2021 at 1:00 PM Vinny Parla (vparla) <vparla=
[email-masked]> wrote:

> Hi Bill,
>
> One of the issues with mTLS is the PKI burden on customers. There also is
> not a good way to convey both device and user  in mTLS (e.g. you can't have
> independent authentications of user and device within the single mTLS
> exchange).  Most of the customers we have spoken with have a preference to
> have both.
>
> -Vinny
>
> I had initially been thinking that it would be good to support both web
> Auth and mutual TLS, but the more I talk with people about it, the more it
> looks like we should just do TLS.  So in the absence of a really compelling
> argument for supporting both, along with all of the future overhead it
> entails, my current position is mutual TLS only.
>
>                                 -Bill
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 26 Oct 2021 14:05:04 -0700

On 10/26/2021 9:49 AM, Bill Woodcock wrote:
>> On Oct 26, 2021, at 6:16 PM, Alec Muffett<[email-masked]>  wrote:
>>
>>
>>
>> On Tue, 26 Oct 2021, 17:10 Vinny Parla (vparla),<vparla=[email-masked]>  wrote:

Mutual TLS would work for DoH, DoT or DoQ, so that seems simpler to support.

-- Christian Huitema