Subject: [Add] ADD WG and Auth-DoH (client authentication)

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 17:51:09 +0000

Hi,

In todays meeting I heard the topic of client authentication of DoH being 
something that was worthy of at least exploring more.  (E.g. how can the DoH 
server advertise its client-auth requirements).

I didn't get a chance to chime in as the IETF session was winding down 
comments at the time.

I am very interested in this topic and believe there are definite use cases 
that would make such a system useful and worthy of being solved.

So in addition to the current topics that were accepted today, I hope we can 
also consider this one at some point in the ADD.

-Vinny

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Jan 2021 12:54:12 -0500

+1

On Wed, Jan 27, 2021 at 12:51 PM Vinny Parla (vparla) <vparla=
[email-masked]> wrote:

> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

-- 
Daniel Migault
Ericsson

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 27 Jan 2021 18:05:36 +0000

+1

I was surprised to hear the chairs describe this as out of scope. If the distinction of "advertising mechanisms used" versus "mechanisms used" addresses that concern, then great. Otherwise, I'd like to hear more.

I'll hold off on diving deeper until we have consensus that this is within scope.

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Daniel Migault
Sent: Wednesday, January 27, 2021 9:54 AM
To: Vinny Parla (vparla) <vparla=[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] ADD WG and Auth-DoH (client authentication)

+1

On Wed, Jan 27, 2021 at 12:51 PM Vinny Parla (vparla) <vparla=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

-Vinny
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca71fc28491114578645108d8c2ec9b64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473668780960941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Fu%2FfQYY438ZfvBhr9CQcB7PemIrpoSG5tciCbt1rQy8%3D&reserved=0>

--
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 27 Jan 2021 13:47:20 -0500

I think I am sharing Tommy's concerns. Just to copy what I put in the chat:
(2021-01-27 12:24:12 PM) mglt: I am upset that advertising Tommy's
mechanism is not in scope of the charter. I do agree that it is not with a
high priority regarding to the drafts we mentioned (deer, home, req)
(2021-01-27 12:24:44 PM) mglt: In other words, I agree we should focus on
deer, home req first.

Yours,
Daniel

On Wed, Jan 27, 2021 at 1:05 PM Tommy Jensen <[email-masked]>
wrote:

> +1
>
>
>
> I was surprised to hear the chairs describe this as out of scope. If the
> distinction of “advertising mechanisms used” versus “mechanisms used”
> addresses that concern, then great. Otherwise, I’d like to hear more.
>
>
>
> I’ll hold off on diving deeper until we have consensus that this is within
> scope.
>
>
>
> Thanks,
>
> Tommy
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of * Daniel Migault
> *Sent:* Wednesday, January 27, 2021 9:54 AM
> *To:* Vinny Parla (vparla) <vparla=[email-masked]>
> *Cc:* ADD Mailing list <[email-masked]>
> *Subject:* [EXTERNAL] Re: [Add] ADD WG and Auth-DoH (client
> authentication)
>
>
>
> +1
>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca71fc28491114578645108d8c2ec9b64%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473668780960941%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Fu%2FfQYY438ZfvBhr9CQcB7PemIrpoSG5tciCbt1rQy8%3D&reserved=0>
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
>

-- 
Daniel Migault
Ericsson

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 27 Jan 2021 19:10:34 +0000

Let me try to clear up my comments by being more specific on the ADD scope discussion.

My comment about “out of scope” was around the use case of Server Side authentication of clients and a server performing an allow/reject on client use.     The workflow or protocol changes for how to that would be out of scope of ADD’s current charter.   Methods to authenticate clients to servers, or methods for servers to identify accepted clients, or what to send to a client to indicate approval/rejection is not in the ADD Charter scope – though certainly such ability and the means to do it have been discussed in other groups.

That was not meant to say that all the various parts needed to do it are out of scope as it may be possible that ADD’s current deliverables may be part of it.

Looking at the ADD Charter (https://datatracker.ietf.org/wg/add/about/) our deliverables are centered around the client: (1) mechanism for client discovery of DNS resolvers…. ; (2) mechanism for communication of DNS resolver information to clients; (3) informational document describing mechanisms for clients to detect specific network environments…

From the charter, I could see the argument that there are pieces of the client authentication-server acceptance use case that could be part of the communication of DNS Resolver information to clients – such as “Yes, I will provide service or No, I won’t provide service to you”.  However, just like the various other use cases ADD has considered the in/out of scope the line would be drawn at the mechanism to convey and would avoid the details of what is being conveyed.   That is to say the mechanism for communicating the needed info would be in scope, but defining of the conveyed information or specifying how it would be used is out of scope – under the current ADD Charter.

In practical terms, someone could writeup the use case and submit as either a standalone document, or potentially as part of something like draft-box-add-requirements so that the potential use case could be potentially considered when working on the groups deliverables.  Ultimately it’s up to the group however is that use-case is accepted as something ADD’s output needs to include.

regards
-Glenn Deen

On 1/27/21, 10:06 AM, "Add on behalf of Tommy Jensen" <[email-masked]<mailto:[email-masked]> on behalf of Jensen.Thomas=[email-masked]<mailto:Jensen.Thomas=[email-masked]>> wrote:

+1

I was surprised to hear the chairs describe this as out of scope. If the distinction of “advertising mechanisms used” versus “mechanisms used” addresses that concern, then great. Otherwise, I’d like to hear more.

I’ll hold off on diving deeper until we have consensus that this is within scope.

Thanks,
Tommy

+1

-Vinny
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fadd&data=04*7C01*7CJensen.Thomas*40microsoft.com*7Ca71fc28491114578645108d8c2ec9b64*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637473668780960941*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2Fu*2FfQYY438ZfvBhr9CQcB7PemIrpoSG5tciCbt1rQy8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PIZeeW5wscynRQ!-S7yyvr74bkwl5BkNyxqsyQW8QXdwmzTQIVGEUp6UIF0k29d5lIWx59gkN_UQEe8$>

--
Daniel Migault
Ericsson

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 27 Jan 2021 15:13:15 -0500

Note that in principle DoT can also support transport-level authentication,
using TLS client certificates.

On Wed, Jan 27, 2021 at 2:10 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> My comment about “out of scope” was around the use case of Server Side
> authentication of clients and a server performing an allow/reject on client
> use.     The workflow or protocol changes for how to that would be out of
> scope of ADD’s current charter.   Methods to authenticate clients to
> servers, or methods for servers to identify accepted clients, or what to
> send to a client to indicate approval/rejection is not in the ADD Charter
> scope – though certainly such ability and the means to do it have been
> discussed in other groups.
>
>
>
> That was not meant to say that all the various parts needed to do it are
> out of scope as it may be possible that ADD’s current deliverables may be
> part of it.
>
>
>
> Looking at the ADD Charter (https://datatracker.ietf.org/wg/add/about/)
> our deliverables are centered around the client: (1) mechanism for client
> discovery of DNS resolvers…. ; (2) mechanism for communication of DNS
> resolver information to clients; (3) informational document describing
> mechanisms for clients to detect specific network environments…
>
>
>
> From the charter, I could see the argument that there are pieces of the
> client authentication-server acceptance use case that could be part of the
> communication of DNS Resolver information to clients – such as “Yes, I will
> provide service or No, I won’t provide service to you”.  However, just like
> the various other use cases ADD has considered the in/out of scope the line
> would be drawn at the mechanism to convey and would avoid the details of
> what is being conveyed.   That is to say the mechanism for communicating
> the needed info would be in scope, but defining of the conveyed information
> or specifying how it would be used is out of scope – under the current ADD
> Charter.
>
>
>
> In practical terms, someone could writeup the use case and submit as
> either a standalone document, or potentially as part of something like
> draft-box-add-requirements so that the potential use case could be
> potentially considered when working on the groups deliverables.  Ultimately
> it’s up to the group however is that use-case is accepted as something
> ADD’s output needs to include.
>
>
>
>
>
> regards
>
> -Glenn Deen
>
>
>
> On 1/27/21, 10:06 AM, "Add on behalf of Tommy Jensen" <
> [email-masked] on behalf of
> Jensen.Thomas=[email-masked]> wrote:
>
>
>
> +1
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of *Daniel Migault
> <https://urldefense.com/v3/__https:/nam06.safelinks.protection.outlook.com/?url=https*3A*2F*2Fwww.ietf.org*2Fmailman*2Flistinfo*2Fadd&data=04*7C01*7CJensen.Thomas*40microsoft.com*7Ca71fc28491114578645108d8c2ec9b64*7C72f988bf86f141af91ab2d7cd011db47*7C1*7C0*7C637473668780960941*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=*2Fu*2FfQYY438ZfvBhr9CQcB7PemIrpoSG5tciCbt1rQy8*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PIZeeW5wscynRQ!-S7yyvr74bkwl5BkNyxqsyQW8QXdwmzTQIVGEUp6UIF0k29d5lIWx59gkN_UQEe8$>
>
>
>
>
> --
>
> Daniel Migault
>
> Ericsson
> --
> Add mailing list
> [email-masked]

---

From: Eric Orth <[email-masked]>
Date: Wed, 27 Jan 2021 15:29:33 -0500

Further refining my statements on this topic from the meeting...

I agree that an actual mechanism to perform the authentication itself is
probably out of scope for this WG.  Probably not even ideal for any
DNS-specific WG since such authentication tends to be a more general
problem.  Also, not entirely clear that any new solutions are needed for
this since DoH/DoT/etc are all based on more general communications
protocols that already have various authentication solutions, e.g., as Ben
notes above, TLS client certs.

But I think that information about or in support of any authentication
mechanisms used by a resolver are absolutely in scope, covered under the
"communication of DNS resolver information to clients" part of the
charter.  Probably not as high priority as the DEER or HOME stuff most of
us agree to be the top priority, but certainly in the realm of a
next-step.  As long as clients are interested in the info, it would be
worth working on.

As for client interest, as I also said in the meeting, Chrome isn't
currently placing much priority on supporting any such client
authentication mechanisms, but I suspect this feature may be of more
interest to OS-based resolvers.  And if OS clients do express interest in
this area, then I think Chrome would be very interested in at least
receiving the information of when resolvers expect/require client
authentication to be used.  Then if the result of resolver
discovery/selection/etc has chosen a resolver that requires such
authentication, if Chrome doesn't support that, Chrome would then know to
delegate host resolution to the OS.

On Wed, Jan 27, 2021 at 3:14 PM Ben Schwartz <bemasc=
[email-masked]> wrote:

> Note that in principle DoT can also support transport-level
> authentication, using TLS client certificates.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jan 2021 20:35:05 +0000

Hiya,

> server advertise its client-auth requirements).

Sorry to have missed that due to a conflict.

> also consider this one at some point in the ADD.

I'd generally be against client auth in DoH and happier if
there were no way to advertise such a desire.

My reasons for being against: clear privacy disimprovement;
the probability of success with a random client seems tiny
and hence servers will have to provide some DNS anyway so I
don't see any point.

Cheers,
S.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 20:51:01 +0000

Hi,
An Enterprise that wants to provide a public facing DoH server would want to 
only have their authenticated users able to groc their enterprise DNS names 
even when those services are exposed in a public facing manner.

For example, vpn.mycompany.com only needs to be known to my users of that 
service and not the entire internet.
App1.myreverseproxy.mycompany.com only needs to be known to my users who need 
to access that service, not the entire internet.

With DoH, I can provision my user's devices to connect to my publicly facing 
Enterprise DoH service, authenticate with it and then allow the properly 
provisioned user devices to access my Enterprise DNS information.

DoH provides privacy to both my Enterprise users and my Enterprise in that 
scenario.

-Vinny

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Sent: Wednesday, January 27, 2021 3:35 PM
To: Vinny Parla (vparla) <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] ADD WG and Auth-DoH (client authentication)

Hiya,

On 27/01/2021 17:51, Vinny Parla (vparla) wrote:
> Hi,
>
> In todays meeting I heard the topic of client authentication of DoH
> being something that was worthy of at least exploring more.  (E.g. how
> can the DoH server advertise its client-auth requirements).

> I am very interested in this topic and believe there are definite use
> cases that would make such a system useful and worthy of being solved.
>
> So in addition to the current topics that were accepted today, I hope
> we can also consider this one at some point in the ADD.

I'd generally be against client auth in DoH and happier if there were no way 
to advertise such a desire.

My reasons for being against: clear privacy disimprovement; the probability of 
success with a random client seems tiny and hence servers will have to provide 
some DNS anyway so I don't see any point.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jan 2021 21:36:04 +0000

Hiya,

> DoH provides privacy to both my Enterprise users and my Enterprise in that

Sure, but there's the obvious way in which this could be
abused for tracking as well. And your enterprise users
can just be provisioned with a different DoH URL so I'm
still not in favour.

S.

---

From: "Vinny Parla (vparla)" <[email-masked]>
Date: Wed, 27 Jan 2021 21:54:51 +0000

Hi,
And that 'different' DoH URL will quickly be learned of and queried by an 
unauthorized user, leading us back to the original problem.

-Vinny

-----Original Message-----
From: Stephen Farrell <[email-masked]>
Sent: Wednesday, January 27, 2021 4:36 PM
To: Vinny Parla (vparla) <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] ADD WG and Auth-DoH (client authentication)

Hiya,

On 27/01/2021 20:51, Vinny Parla (vparla) wrote:
> Hi,
> An Enterprise that wants to provide a public facing DoH server would
> want to only have their authenticated users able to groc their
> enterprise DNS names even when those services are exposed in a public facing 
> manner.
>
> For example, vpn.mycompany.com only needs to be known to my users of
> that service and not the entire internet.
> App1.myreverseproxy.mycompany.com only needs to be known to my users
> who need to access that service, not the entire internet.
>
> With DoH, I can provision my user's devices to connect to my publicly
> facing Enterprise DoH service, authenticate with it and then allow the
> properly provisioned user devices to access my Enterprise DNS information.
>
> DoH provides privacy to both my Enterprise users and my Enterprise in
> that scenario.

Sure, but there's the obvious way in which this could be abused for tracking 
as well. And your enterprise users can just be provisioned with a different 
DoH URL so I'm still not in favour.

S.

>> being something that was worthy of at least exploring more.  (E.g.
>> how can the DoH server advertise its client-auth requirements).
>
>> I didn't get a chance to chime in as the IETF session was winding
>> down comments at the time.
>>
> I'd generally be against client auth in DoH and happier if there were
> no way to advertise such a desire.
>
> My reasons for being against: clear privacy disimprovement; the
> probability of success with a random client seems tiny and hence
> servers will have to provide some DNS anyway so I don't see any point.
>
> Cheers,
> S.
>
>>
>> -Vinny
>>
>>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jan 2021 14:06:38 -0800

Is this something we have to resolve right now?

This seems like just another parameter to DEER. Given that DEER is built on
top of SVCB and new parameters are defined via Expert Review, it seems like
something to indicate the desired type of authentication could be defined
at any time in the future without architectural changes.

With that said, I'm somewhat skeptical that such an extension will be
needed: clients will need to be provisioned with credentials in any case
for this to work, and whatever mechanism is used to provision those
credentials can probably be used to configure which resolvers to use and
when to use the credentials. But presumably that's something that could be
sorted out in the future.

-Ekr

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 27 Jan 2021 22:37:36 +0000

What do you mean by resolve? I think we should discuss what use cases the WG should queue up next (which was the main question of the first presentation). Is your point here that the WG should avoid multi-tasking to keep focus on the drafts adopted or up for adoption? I'm hoping collectively the WG can do both in parallel; perhaps that's being optimistic.

I agree this initially feels like something we could add to DEER. As Tommy, Vittorio, and others mentioned, we would want that to be a signal format shared between the two current discovery drafts in focus.

I will point out that username/password based auth may not have had endpoint configuration (ex: BYOD for an employee who knows their login but has no employer software installed on their device).

Thanks,
Tommy

From: Add <[email-masked]> On Behalf Of Eric Rescorla
Sent: Wednesday, January 27, 2021 2:07 PM
To: Vinny Parla (vparla) <vparla=[email-masked]>
Cc: ADD Mailing list <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: [EXTERNAL] Re: [Add] ADD WG and Auth-DoH (client authentication)

This seems like just another parameter to DEER. Given that DEER is built on top of SVCB and new parameters are defined via Expert Review, it seems like something to indicate the desired type of authentication could be defined at any time in the future without architectural changes.

With that said, I'm somewhat skeptical that such an extension will be needed: clients will need to be provisioned with credentials in any case for this to work, and whatever mechanism is used to provision those credentials can probably be used to configure which resolvers to use and when to use the credentials. But presumably that's something that could be sorted out in the future.

-Ekr

On Wed, Jan 27, 2021 at 1:55 PM Vinny Parla (vparla) <vparla=[email-masked]<mailto:[email-masked]>> wrote:
Hi,
And that 'different' DoH URL will quickly be learned of and queried by an
unauthorized user, leading us back to the original problem.

-Vinny

-----Original Message-----
From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 27, 2021 4:36 PM
To: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] ADD WG and Auth-DoH (client authentication)

Hiya,

On 27/01/2021 20:51, Vinny Parla (vparla) wrote:
> For example, vpn.mycompany.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvpn.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310696915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e8fTJfOt5uo%2BdmaO0QdixqxyxTRql0lX35D%2BnOHHf8c%3D&reserved=0> only needs to be known to my users of
> App1.myreverseproxy.mycompany.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapp1.myreverseproxy.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310701902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xif6uKJPRxfVqxlL0RsSX3UPOqpsbPNbF452Ril5y7w%3D&reserved=0> only needs to be known to my users

S.

> From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
> To: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>; ADD Mailing list
> <[email-masked]<mailto:[email-masked]>>
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310706891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7QmzVB1R9BH9DXDcW%2BV1gAX0v1tHM%2FIguurraJsY4X4%3D&reserved=0>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jan 2021 14:48:49 -0800

On Wed, Jan 27, 2021 at 2:37 PM Tommy Jensen <[email-masked]>
wrote:

> What do you mean by resolve? I think we should discuss what use cases the
> WG should queue up next (which was the main question of the first
> presentation). Is your point here that the WG should avoid multi-tasking to
> keep focus on the drafts adopted or up for adoption?
>

Yes, that's what I think.

>
> I agree this initially feels like something we could add to DEER. As
> Tommy, Vittorio, and others mentioned, we would want that to be a signal
> format shared between the two current discovery drafts in focus.
>
>
>
> I will point out that username/password based auth may not have had
> endpoint configuration (ex: BYOD for an employee who knows their login but
> has no employer software installed on their device).
>

Sure, this seems like an argument that this might be usefully signaled.

-Ekr

>
> Thanks,
>
> Tommy
>
>
>
> *From:* Add <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Wednesday, January 27, 2021 2:07 PM
> *Cc:* ADD Mailing list <[email-masked]>; Stephen Farrell <
> [email-masked]>
> This seems like just another parameter to DEER. Given that DEER is built
> on top of SVCB and new parameters are defined via Expert Review, it seems
> like something to indicate the desired type of authentication could be
> defined at any time in the future without architectural changes.
>
>
>
> > For example, vpn.mycompany.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvpn.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310696915%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=e8fTJfOt5uo%2BdmaO0QdixqxyxTRql0lX35D%2BnOHHf8c%3D&reserved=0>
> only needs to be known to my users of
> > App1.myreverseproxy.mycompany.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapp1.myreverseproxy.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310701902%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xif6uKJPRxfVqxlL0RsSX3UPOqpsbPNbF452Ril5y7w%3D&reserved=0>
> only needs to be known to my users
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7C522a4bc0d2b946b249c208d8c310187d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473821310706891%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7QmzVB1R9BH9DXDcW%2BV1gAX0v1tHM%2FIguurraJsY4X4%3D&reserved=0>
>
>

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 27 Jan 2021 22:54:34 +0000

Thanks ekr; that helps me put this thread into context. I agree that DEER and the DHCP/RA Options drafts are top priority until they (or some iteration of them) get to WGLC.

Thanks,
Tommy

From: Eric Rescorla <[email-masked]>
Sent: Wednesday, January 27, 2021 2:49 PM
To: Tommy Jensen <[email-masked]>
Cc: vparla=[email-masked]; [email-masked]; [email-masked]
Subject: Re: [EXTERNAL] Re: [Add] ADD WG and Auth-DoH (client authentication)

On Wed, Jan 27, 2021 at 2:37 PM Tommy Jensen <[email-masked]<mailto:[email-masked]>> wrote:
What do you mean by resolve? I think we should discuss what use cases the WG should queue up next (which was the main question of the first presentation). Is your point here that the WG should avoid multi-tasking to keep focus on the drafts adopted or up for adoption?

-Ekr

Thanks,
Tommy

From: Add <[email-masked]<mailto:[email-masked]>> On Behalf Of Eric Rescorla
Sent: Wednesday, January 27, 2021 2:07 PM
To: Vinny Parla (vparla) <vparla=[email-masked]<mailto:[email-masked]>>
Cc: ADD Mailing list <[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: [EXTERNAL] Re: [Add] ADD WG and Auth-DoH (client authentication)

-Ekr

-Vinny

-----Original Message-----
From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 27, 2021 4:36 PM
To: Vinny Parla (vparla) <[email-masked]<mailto:[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] ADD WG and Auth-DoH (client authentication)

Hiya,

On 27/01/2021 20:51, Vinny Parla (vparla) wrote:
> For example, vpn.mycompany.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fvpn.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca821833cbcf346aa53ea08d8c315cd74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473845832439955%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5Rkc6CFeqTD9np8llNCdx1%2B02e5AF61Y%2F3hToPW%2BBXI%3D&reserved=0> only needs to be known to my users of
> App1.myreverseproxy.mycompany.com<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapp1.myreverseproxy.mycompany.com%2F&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca821833cbcf346aa53ea08d8c315cd74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473845832444949%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=bvg%2FkY2og4U4a5hGAEGVf9a4Xdb2tRBpucxehFlpZ%2B0%3D&reserved=0> only needs to be known to my users

S.

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=04%7C01%7CJensen.Thomas%40microsoft.com%7Ca821833cbcf346aa53ea08d8c315cd74%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637473845832449935%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=40ARdVbq4Kywthqn8p%2FXUTOg69mFg0zp%2Fi%2F1bG2IU5c%3D&reserved=0>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 27 Jan 2021 23:07:32 +0000

Hiya,

On 27/01/2021 22:37, Tommy Jensen wrote:
> endpoint configuration (ex: BYOD for an employee who knows their
> login but has no employer software installed on their device).
There could be interesting phishing vectors there. Might be
that 2021 is a good time to stop encouraging that. In any
case it's not clear to me there's an overall win in adding a
pure username/password authentication scheme in this case
where the name of the entity to which the password will be
visible likely has no meaning to the user. Taking the risk
that intranet names leak (which they will anyway in lots of
documents) would often be the overall less risky option I'd
say.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Jan 2021 15:20:12 -0800

On Wed, Jan 27, 2021 at 3:07 PM Stephen Farrell <[email-masked]>
wrote:

> There could be interesting phishing vectors there

Finally a use for TLS + PAKE!

-Ekr

---

From: "Robert Mortimer" <[email-masked]>
Date: Thu, 28 Jan 2021 13:10:00 +0000

just to add a +1 to this
it was something that was very much of enterprise in my last role - authenticating the client would be extremely useful for enterprises or anyone that wants to run their own DoH server but doesn't want to run a public DoH server.

Even as a private individual I might want to provide DoH services to myself regardless of the network I'm on but not want to run a public DoH resolver so client authentication would be vital to enable this.

On 27/01/2021 17:52:23, Vinny Parla (vparla) <vparla=[email-masked]> wrote:
Hi,

-Vinny

---

From: tirumal reddy <[email-masked]>
Date: Fri, 29 Jan 2021 11:31:53 +0530

> Finally a use for TLS + PAKE!

Yes, TLS + PAKE seems useful for a BYOD to authenticate the HTTPS PvD
server to securely discover the encrypted DNS resolver information conveyed
as additional PvD information. TLS + PAKE can also be used to authenticate
the roaming BYOD to a public Enterprise DNS server.

Any plans to revive draft-barnes-tls-pake ?

-Tiru