Subject: [Add] Updated charter proposal for ADD

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Jan 2020 14:38:21 -0800

Hi all,

I wanted to share an updated proposal for an ADD charter, based on the feedback and discussion on the list in the past several weeks.

This is based on the original proposal that was sent in December, taking into account various comments and suggestions. Glenn Deen, Andrew Campling, and I worked on this revision together and came to consensus on its contents.

Thoughts and comments are welcome as always!

(Note that the proposed name of the group was not changed, and is entirely open to bikeshedding. Naming is hard!)

Best,
Tommy

Adaptive DNS Discovery (ADD)
====================================
Proposed Working Group Charter

Sending DNS messages over encrypted transports, as defined in DNS over
TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides
benefits to the security and privacy of DNS data. Clients, such as
applications and host operating systems, have started adopting these
protocols to provide these user benefits.

This working group will focus on discovery and selection of DNS resolvers
by DNS clients in a variety of networking environments, including public
networks, private networks, and VPNs; supporting both encrypted and
unencrypted resolvers.

Clients adopting encrypted DNS protocols need to determine which DNS
servers support encrypted transports, and which server to use for specific
queries if multiple servers are available. These decisions can vary based
on the network environment, and also based on the content and purpose of
the client queries.

Network operators that start offering DNS encryption on their servers also
need a way to indicate this support to clients. Communicating information
about resolver configuration and behavior allows clients to make more
informed decisions about which DNS servers to use. For example, a resolver
may be able to resolve private or local names as a split DNS server.

The Adaptive DNS Discovery (ADD) working group will work on the following
deliverables:

- define a mechanism that allows clients to discover DNS resolvers,
including encrypted DNS servers, that are available to the client
either on the public Internet or on private or local networks;

- define a mechanism that allows communication of DNS resolver
information to clients for use in selection decisions;

- develop an informational document that describes how client
applications and systems can manage selection of DNS resolvers
in various network environments and use cases.

Any mechanisms that specify interactions between clients and
servers must provide the security properties expected of IETF
protocols, e.g., confidentiality protection, integrity protection,
and authentication with strong work factor.

This working group will coordinate with dnsop, doh, and dprive for any
changes required in DNS protocols. It will also work with capport to
ensure that solutions are applicable to captive networks.

---

From: Neil Cook <[email-masked]>
Date: Wed, 15 Jan 2020 11:12:53 +0000

I agree with Stephen Farrell's comments on the other thread on this topic, namely:

> On 14 Jan 2020, at 23:23, Stephen Farrell <[email-masked]> wrote:

> I do think there's value in opportunistic approaches so
> long as there's some kind of credible longer term story
> as to how we get to better than opportunistic. I read
> your charter text as strongly discouraging that.
Neil

> On 14 Jan 2020, at 22:38, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> Hi all,
> 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

Neil Cook
[email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG, Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Michael Knapstein, Stephan Martin 
Chairman of the Board: Richard Seibt

European Office: 
Open-Xchange GmbH, Olper Huette 5f, D-57462 Olpe, Germany, District Court Siegen, HRB 8718 
Managing Director: Frank Hoberg

US Office: 
Open-Xchange. Inc., 530 Lytton Avenue, Palo Alto, CA 94301, USA 
-------------------------------------------------------------------------------------

---

From: Paul Adair <[email-masked]>
Date: Wed, 15 Jan 2020 13:07:21 +0000

I support the charter as written.

Paul Adair
Infoblox

On 1/14/20, 4:38 PM, "Add on behalf of Tommy Pauly" <[email-masked] on behalf of tpauly=[email-masked]> wrote:

    Hi all,

    

    Best,
    Tommy

    

    

    

    
    
    -- 
    Add mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$

---

From: "Diego R. Lopez" <[email-masked]>
Date: Wed, 15 Jan 2020 13:12:13 +0000

+1

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
https://www.linkedin.com/in/dr2lopez/

e-mail: [email-masked]
Tel:         +34 913 129 041
Mobile:  +34 682 051 091
----------------------------------

On 15/01/2020, 14:07, "Add on behalf of Paul Adair" <[email-masked] on behalf of [email-masked]> wrote:

    Paul Adair
    Infoblox

        Hi all,

        Best,
        Tommy

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jan 2020 15:13:09 +0000

The following paragraph in the proposed charter is impossible to meet for the vast majority of use cases that have been discussed on this list:

Any mechanism whose understanding of the network and network services comes from interactions that were not cryptographically authenticated (such as DHCP and RA) cannot meet those requirements.

The presence of that paragraph will basically stop work being done in the WG once it is chartered. Please strongly consider removing it. Without that paragraph, the charter seems fine.

--Paul Hoffman

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 15 Jan 2020 15:37:05 +0000

I also support this charter & appreciate the hard work done to try to move to a consensus view (thanks Tommy & Glenn in particular).

A number of folks have objected to the "Any mechanism..." paragraph - so removal of that seems fine.

Jason

On 1/14/20, 5:39 PM, "Add on behalf of Tommy Pauly" <[email-masked] on behalf of tpauly=[email-masked]> wrote:

    Hi all,

    Best,
    Tommy

    --
    Add mailing list
    [email-masked]
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!CQl3mcHX2A!TKpnzyf-ATAppvFlL-4frLIh8Q5rzbJdvXIsHTKvpJTfV_ukdwc8AgjsYWI6snmjuppSDw$

---

From: "Robert Mortimer" <[email-masked]>
Date: Wed, 15 Jan 2020 15:42:42 +0000

+1

-- 
Robm
873
  "Ask not what I can do for the stupid, 
         but what the stupid can do for me" - Graeme Garden
On 15/01/2020 15:15:09, Paul Hoffman <[email-masked]> wrote:
The following paragraph in the proposed charter is impossible to meet for the vast majority of use cases that have been discussed on this list:

--Paul Hoffman--
Add mailing list
[email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Wed, 15 Jan 2020 15:45:21 +0000

+1

Andrew

-----Original Message-----
From: Paul Adair <[email-masked]>
Sent: 15 January 2020 13:07
To: Tommy Pauly <tpauly=[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] Updated charter proposal for ADD

Paul Adair
Infoblox

On 1/14/20, 4:38 PM, "Add on behalf of Tommy Pauly" <[email-masked] on behalf of tpauly=[email-masked]<mailto:[email-masked]%20on%20behalf%20of%20tpauly=[email-masked]>> wrote:

    Hi all,

    Best,
    Tommy

    --
    Add mailing list
    [email-masked]<mailto:[email-masked]>
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 10:46:54 -0500

> Any mechanism whose understanding of the network and network services comes from interactions that were not cryptographically authenticated (such as DHCP and RA) cannot meet those requirements.

Rather than just deleting this text, which I agree is probably not what we want, how about fixing it?

Any specification must include a clear and thorough discussion of the privacy and security implications of using the method or methods it describes.  Methods where a mechanism that cannot be cryptographically validated for integrity or which do not provide a cryptographically validatable trust establishment mechanism will clearly describe the use case(s) in which such an override is thought to be needed, should have a clear applicability statement limiting the scope of the specification to those use case(s), and should clearly describe the risks and benefits of such a choice.

The first sentence is unnecessary since this is what is expected in the IETF anyway, but it sets the stage for the sentences that follow.   The point of this is not to prevent the WG specifying methods that can’t be cryptographically validated for integrity and/or trust, but rather to make it clear that such a specification would not be in charter if it didn’t meet the stated requirements.

---

From: Dave Lawrence <[email-masked]>
Date: Wed, 15 Jan 2020 10:54:10 -0500

> what we want, how about fixing it?  

That's where I am on this.  I like the proposal as a whole and just
think this little bit on the security properties needs tweaking.  I've
got to run at the moment though and apologize for not having a
concrete proposal for the tweak.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 15 Jan 2020 18:09:40 +0200

Thanks for this, Tommy.

I support this charter, and I think it is important work. I have two further points to make, on areas where we may wish to make changes (but I can live with current charter).

1. I think the third paragraph would benefit from an observation that the choices have implications. I’d suggest this tweak:
OLD:
These decisions can vary based on the network environment, and also based on the content and purpose of the client queries.
NEW:
These decisions can vary based on the network environment, and also based on the content and purpose of the client queries. The decisions may have implications on reachability, privacy, and so on.

2. As noted, the paragraph on “any mechanisms” has some issues, and could be either removed (can live with that) or improved (can live with that as well, as long as the improvement process terminates…)

Jari

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jan 2020 16:18:11 +0000

> Rather than just deleting this text, which I agree is probably not what we want, how about fixing it?

Because I don't think we can get consensus on the fixed wording *for the charter*. I would prefer to have the consensus discussions for the documents themselves.

> Any specification must include a clear and thorough discussion of the privacy and security implications of using the method or methods it describes.  Methods where a mechanism that cannot be crypto…

The first sentence is well-intentioned but does not usually lead to useful text in documents. The second sentence assumes that there are methods that can be cryptographically validated: as I said above, I do not believe they exist.

> The first sentence is unnecessary since this is what is expected in the IETF anyway,

Fully agree.

> but it sets the stage for the sentences that follow.

...and thus is unnecessary.

>   The point of this is not to prevent the WG specifying methods that can’t be cryptographically validated for integrity and/or trust, but rather to make it clear that such a specification would not be in charter if it didn’t meet the stated requirements.

Again, we disagree here because I (and others) don't agree that such methods exist.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 11:18:43 -0500

> concrete proposal for the tweak.

In case it’s not obvious, this is what I was proposing for a tweak:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 11:48:06 -0500

> The first sentence is well-intentioned but does not usually lead to useful text in documents. The second sentence assumes that there are methods that can be cryptographically validated: as I said a…

Of course such mechanisms exist.   The problem is that they can’t happen without some explicit trust establishment mechanism, which necessarily requires manual intervention.

What I want to capture is that any mechanism that the ADD WG comes up with that doesn’t have a trust establishment mechanism doesn’t override a mechanism where trust has been established explicitly unless there’s some specific reason why that’s the right thing to do.  E.g., Tommy I think mentioned, and this is a use case I deal with regularly as well, that you might be connected to a network that uses a split-dns configuration where if you query a public resolver, you just won’t get an answer for some domain.  I think that there is a pretty strong motivation from some of the participants to support a use case for CDNs; figuring out how to do this seems like it would be very much worthwhile, even if such a mechanism doesn’t come with an explicit trust relationship.

I would expect that a trust establishment mechanism based on the ANIMA on-boarding process (IETF) or the Thread commissioning process (Thread Group) would also be cryptographically verifiable, since devices commissioned using either mechanism can in fact cryptographically validate that they are connected to a particular network; it’s not a big step past that to validating the resolver.   If course, for a device that doesn’t have any such configuration established, a simple DHCP mechanism or RA mechanism for getting opportunistic security is still very much worth doing.

That said, I think it is in scope for the WG to talk about configuration mechanism that require manual intervention and do establish cryptographically verifiable trust.   Do you disagree with that?   To me this seems like an important part of the problem space.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 Jan 2020 12:19:27 -0500

> think this little bit on the security properties needs tweaking.

I may have been the one to originally propose this language to Tommy and others, and I recognize that was a bit of an error. The formulation in the charter text that Ben Schwartz circulated seems more workable (plus dropping the “any” before “mechanisms”):

"Where possible, mechanisms that specify exchange of information between clients and resolvers should provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor.  Each specification must clearly indicate under what circumstances and assumptions these properties are or are not provided.”

I think this would be a good guidepost to have in the charter, and is less prescriptive than the tweak offered by Ted Lemon. But from my POV it’s just a nice-to-have if it’s not so controversial that its inclusion prevents the charter from being approved.

Alissa

>  I've

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Jan 2020 17:28:39 +0000

> On Jan 15, 2020, at 8:48 AM, Ted Lemon <[email-masked]> wrote:
> 

Fair point. They exist but they cannot be used in the Internet as we know it. That's why I believe they are not worth mentioning in the WG charter.

> I would expect that a trust establishment mechanism based on the ANIMA on-boarding process (IETF) or the Thread commissioning process (Thread Group) would also be cryptographically verifiable, since devices commissioned using either mechanism can in fact cryptographically validate that they are connected to a particular network; it’s not a big step past that to validating the resolver.  

In both those models, I believe, an individual specifies a source of trust and a public key for that source of trust. From that point forward, the source of trust can announce anything it wants; all that remains to define is an announcement format and expected communications paths. That seems fine.

> If course, for a device that doesn’t have any such configuration established, a simple DHCP mechanism or RA mechanism for getting opportunistic security is still very much worth doing.

Fully agree.

> That said, I think it is in scope for the WG to talk about configuration mechanism that require manual intervention and do establish cryptographically verifiable trust.   Do you disagree with that?…

I strongly disagree with the second part of the first sentence "and do establish cryptographically verifiable trust", which is why I disagree with the inclusion of text in the charter that hints that this WG has any part in the setup of trust. In my view (which at least some others seem to share), either you have cryptographic trust to a source already set up (ANIMA, old skool secure DHCP, Some Vendor Says So, ...), or you have none and whatever you hear on the network can only be trusted by leap of faith. All proposals between those have historically led to ratholes, and thus I would like to leave them out of the charter.

--Paul Hoffman

---

From: Rob Sayre <[email-masked]>
Date: Wed, 15 Jan 2020 11:24:02 -0800

On Wed, Jan 15, 2020 at 7:48 AM Ted Lemon <[email-masked]> wrote:

> Any mechanism whose understanding of the network and network services
> comes from interactions that were not cryptographically authenticated (such
> as DHCP and RA) cannot meet those requirements.
>
>

It might help to understand how people are planning to deploy DoH/DoT on
local networks. Right now, my DNS server is 192.168.86.1, and encrypted DNS
seems designed to bypass it.

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Wed, 15 Jan 2020 19:47:35 +0000

On Wed, Jan 15, 2020 at 19:24 Rob Sayre <[email-masked]> wrote:
> Right now, my DNS server is 192.168.86.1, and encrypted DNS seems designed to bypass it.

Although not critical to the content of the charter, I think it would be interesting if you could expand on this.

Andrew

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Jan 2020 14:54:22 -0500

I understand the interest in a statement such as this, but I don't
really see a need for it: We have established needs for Security
Considerations, we have Security ADs who will be checking for proper
coverage, and we're most likely to include an assigned technical
advisor from the Security Area when we establish the working group.

So, while some sort of discussion in the charter might not be harmful,
it doesn't seem necessary and seems sure to cause a lot of angst in
getting agreement on the wording.

Barry

---

From: <[email-masked]>
Date: Wed, 15 Jan 2020 20:00:02 +0000

Rob's 192.168.86.1 seems to be one particular use case. The working group should consider all use cases, and I think this charter does that.

I support the creation of a working group based on it, ideally as amended by Jari's tweaks. The first of these seems sensible, and for the second I can live with either removal of the security paragraph, or an updated version of it.

At the end of the day we all want to make it as secure and robust as possible, so the concensus process will send it in that direction, regardless of the presence of a charter security paragraph. I agree with Barry that it doesn't seem to be needed.

The main point is we should start this work on discovery, communication of resolver info, and selection possibilities.

Chris

> From: Add <[email-masked]> On Behalf Of Jari Arkko
> 
> 1. I think the third paragraph would benefit from an observation that the
> choices have implications. I’d suggest this tweak:
> OLD:
> These decisions can vary based on the network environment, and also
> based on the content and purpose of the client queries.
> NEW:
> These decisions can vary based on the network environment, and also
> based on the content and purpose of the client queries. The decisions may
> have implications on reachability, privacy, and so on.
> 
> 2. As noted, the paragraph on “any mechanisms” has some issues, and
> could be either removed (can live with that) or improved (can live with that
> as well, as long as the improvement process terminates…)

---

From: Rob Sayre <[email-masked]>
Date: Wed, 15 Jan 2020 12:03:07 -0800

> > Right now, my DNS server is 192.168.86.1, and encrypted DNS seems

Well, a lot of networking products (both consumer and corporate) have an
unencrypted DNS server on a private IP.

I was wondering how the certificates would be constructed if they wished to
offer DoH or DoT. I know public services are able to get certificates with
SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for
1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering
how private networks will offer encrypted DNS, and whether the debate
around the security considerations is important.

thanks,
Rob

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Jan 2020 12:49:29 -0800

On Wed, Jan 15, 2020 at 12:03 PM Rob Sayre <[email-masked]> wrote:

> I was wondering how the certificates would be constructed if they wished
> to offer DoH or DoT. I know public services are able to get certificates
> with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for
Certificates can be self-signed.
Self-signed certificates' fingerprints can be published in any
corresponding DNS zone as TLSA records with the right subtype (2 or 3) that
does not require PKI.
Names for the DNS zones, certificates, and resolvers' host names can be
from private-use portions of the namespace (such as has been proposed for
use in the reserved portion of ISO 2-letter codes, like .zz).
The client security can then be reduced to learning or distributing DNSSEC
trust anchors for resolvers, including possibly doing "trust on first use"
methods and well-known names.
I.e. client queries well-known name for a pointer to the resolver's own
name, along with a corresponding trust anchor for that name (name of a DNS
zone).
Once the trust anchor is available, everything else can bootstrap from
that, including TLSA records (which give TLS fingerprints for certificates,
which would be self-signed and validated without PKI, using the TLSA
mechanisms.)

I'm doing a proof of concept on this as we speak.

Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 15 Jan 2020 21:00:32 +0000

On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:
> Right now, my DNS server is 192.168.86.1, and encrypted DNS seems designed to bypass it.

Well, a lot of networking products (both consumer and corporate) have an unencrypted DNS server on a private IP.

I was wondering how the certificates would be constructed if they wished to offer DoH or DoT. I know public services are able to get certificates with SAN[1] extensions containing public IPs (e.g. the Cloudflare cert for 1.1.1.1). That doesn't seem to make sense for private IPs, so I'm wondering how private networks will offer encrypted DNS, and whether the debate around the security considerations is important.

thanks,
Rob

[1] https://tools.ietf.org/html/rfc5280#section-4.2.1.6<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5280-23section-2D4.2.1.6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=8_yvv1il3zewjGy7Q4S4OtQitnmASPvjF6La_TDH_6U&s=DIByZeZTbnVQz-bhge3oVFvDzYJTHKdgueM0_z-8W7s&e=>

<bhs> Discussions I’ve had with people so far have been along the lines of (1) we’re not aware of any user-friendly/easy way to get a certificate into consumer routers that will be ok’ed by a CA in browsers’ trust stores, (2) the user experience of doing https to a consumer router from a browser is pretty horrible and scary, (3) some of these routers (e.g., Netgear) don’t even allow users to change what the router sends in DHCP/RA (it’s always the router’s private IP address; but the user can change what recursive resolver the router then uses), and (4) many people are unconvinced that the threat of compromise inside the home network is worth the effort and negative user experience.</bhs>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 16:25:16 -0500

> advisor from the Security Area when we establish the working group.

At present there are no /IETF/ specifications that talk about trust relationships between hosts and resolvers for DoH or DoT.   So from the IETF perspective, this is a green-field working group charter.   The working group could start out by doing a specification that defines a DHCP option, or an RA option, which could be MTI.  The IESG would have no particular reason to reject this proposal.  This as-yet-to-be-named security advisor might or might not consider this to be a problem.

If you consider it to be the case that the working group should be doing this anyway, then there can’t possibly be any harm in putting this in the charter.  If we put it in the charter, then when the last call comes along, we can point to the charter and say “this isn’t in the charter.”  That seems like a good thing to be able to do, and seems like it would cause no harm if what you are saying is true.

That said, I have not actually heard anybody other than you and Paul object to the new language I proposed, and Paul’s objection appears to be semantic rather than functional.

So where is this pushback coming from?

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Jan 2020 13:26:08 -0800

On Wed, Jan 15, 2020 at 1:01 PM STARK, BARBARA H <[email-masked]> wrote:

>
>
> On Wed, Jan 15, 2020 at 11:47 AM Andrew Campling <
> [email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc5280-23section-2D4.2.1.6&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=8_yvv1il3zewjGy7Q4S4OtQitnmASPvjF6La_TDH_6U&s=DIByZeZTbnVQz-bhge3oVFvDzYJTHKdgueM0_z-8W7s&e=>
>
>
>
> <bhs> Discussions I’ve had with people so far have been along the lines of
> (1) we’re not aware of any user-friendly/easy way to get a certificate into
> consumer routers that will be ok’ed by a CA in browsers’ trust stores, (2)
> the user experience of doing https to a consumer router from a browser is
> pretty horrible and scary, (3) some of these routers (e.g., Netgear) don’t
> even allow users to change what the router sends in DHCP/RA (it’s always
> the router’s private IP address; but the user can change what recursive
> resolver the router then uses), and (4) many people are unconvinced that
> the threat of compromise inside the home network is worth the effort and
> negative user experience.</bhs>
>
>
The other relevant question for those consumer boxes is whether they are
full resolvers, or if they are merely forwarders to an upstream resolver
that they learn from e.g. DHCP or RA. (Some even advertise their own IP,
but only do NAT without any real DNS functionality, and literally forwarder
the packet, rather than the query, from what I understand.)

If the upstream resolver can be identified and is reachable directly, that
potentially makes the middle box a moot point, as the client would have the
ability to do whatever the WG adopts, to the real upstream resolver.

Making that sufficiently user-friendly on the client side, and scalable and
operable on the resolver side, are pertinent questions. I expect the user
experience would be better, and the security model much better, when
bypassing the middle box.

The threat potential would still exist outside of the home network if a
forwarder was used without using an upgraded transport, between the middle
box and the upstream resolver. This threat would be addressed indirectly
if/when the middle box were bypassed entirely.

This model presumes the upstream resolver is the resolver discovered, and
would not change the actual (functional) resolver being used.

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jan 2020 21:30:21 +0000

Hiya,

On 15/01/2020 21:25, Ted Lemon wrote:
> That said, I have not actually heard anybody other than you and Paul
> object to the new language I proposed,
FWIW, I don't your suggestion solves the problem.

(Without arguing for any particular outcome) I'd like
the WG to be able to consider opportunistic solutions
as well as strongly authenticated ones. I read your
text as strongly arguing that the former (oppo) not
be included.

To be clear - personally, I'd argue against a whole
bunch of the opportunistic solutions I could envisage
in this space, but maybe not all of 'em.

Cheers,
S.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 16:32:24 -0500

FWIW, for those who aren’t aware of this, the main point of having a DNS Proxy on your home router (at 192.168.1.1, for example), the reason is primarily timing.   The ISP might change the IP address of the DNS server (although it rarely does), but more importantly if there is a power failure, and your home router becomes reachable before the ISP connection comes up, and your host connects to it during that gap, the router won’t have a DNS server IP address to offer your host other than its own.

For the case where we want the home router to support a secure DNS resolver, the proxy could simply be a tunnel to the DNS resolver: before the ISP connection comes up, names can’t be resolved, so there’s no problem, and when it does come up, then the TLS handshake will actually be with the ISP’s resolver, which will have an identity, not with the home router.

Even if the home router offers a value-added resolver service, the same principle would likely apply.   So before we go off and invent solution to this problem, we should make sure we need a solution.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 16:33:03 -0500

> text as strongly arguing that the former (oppo) not

OK, if that’s the case then the wording is wrong, because I very much support the opportunistic solution.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 15 Jan 2020 14:20:25 -0800

On Wed, Jan 15, 2020 at 1:32 PM Ted Lemon <[email-masked]> wrote:

> FWIW, for those who aren’t aware of this, the main point of having a DNS
> Proxy on your home router (at 192.168.1.1, for example), the reason is
> primarily timing.
>

The point wasn't limited to home routers, although it does apply there.

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 17:27:05 -0500

> The point wasn't limited to home routers, although it does apply there.

OK.   For an enterprise user, the easiest thing to do is just get a cert.   The IP address doesn’t matter.   If you want to use ACME, you might need to do some gymnastics, but you can make it work.   An operational document that describes how this works might be useful.   I don’t think there’s any new protocol work to do here.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 15 Jan 2020 14:49:00 -0800

On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon <[email-masked]> wrote:

> OK.   For an enterprise user, the easiest thing to do is just get a cert.
>   The IP address doesn’t matter.   If you want to use ACME, you might need
> to do some gymnastics, but you can make it work.   An operational document
> that describes how this works might be useful.   I don’t think there’s any
> new protocol work to do here.
>

I agree. When I read the charter, I'm wondering what's not possible today
that these deliverables would enable, and why split DNS would be in scope,
rather than an item for CAPPORT (
https://datatracker.ietf.org/wg/capport/about/ for those who aren't
familiar).

thanks,
Rob

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 16 Jan 2020 09:52:29 +1100

On Thu, Jan 16, 2020, at 02:13, Paul Hoffman wrote:
> The following paragraph in the proposed charter is impossible to meet 
> for the vast majority of use cases that have been discussed on this 
> list:
> 

Would it be better if the charter said that the work products must include mechanisms that provide or allow for <listed properties>, but that mechanisms might only provide opportunistic security [cite RFC].

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 18:00:07 -0500

On Jan 15, 2020, at 5:49 PM, Rob Sayre <[email-masked]> wrote:
> I agree. When I read the charter, I'm wondering what's not possible today that these deliverables would enable, and why split DNS would be in scope, rather than an item for CAPPORT (https://datatracker.ietf.org/wg/capport/about/ <https://datatracker.ietf.org/wg/capport/about/> for those who aren't familiar). 

I think split DNS is pretty clearly in scope—it’s a very different problem than CAPPORT.   If the language I suggested seems to you to suggest that split DNS is not in scope, I didn’t word it well (which sounds likely given Stephen’s reaction to it).

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Wed, 15 Jan 2020 23:00:27 +0000

On Jan 15, 2020, at 2:49 PM, Rob Sayre <[email-masked]> wrote:

On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:
On Jan 15, 2020, at 5:20 PM, Rob Sayre <[email-masked]<mailto:[email-masked]>> wrote:
The point wasn't limited to home routers, although it does apply there.

I agree. When I read the charter, I'm wondering what's not possible today that these deliverables would enable, and why split DNS would be in scope, rather than an item for CAPPORT (https://datatracker.ietf.org/wg/capport/about/ for those who aren't familiar).

Ideally the WG product would be general enough to work for any dns discovery and selection situation including split dns.   So keeping it in scope would seem useful.   Certainly this group will talk to capport.

Glenn

---

From: Brian Dickson <[email-masked]>
Date: Wed, 15 Jan 2020 15:13:17 -0800

On Wed, Jan 15, 2020 at 2:27 PM Ted Lemon <[email-masked]> wrote:

> that describes how this works might be useful.
>

> I don’t think there’s any new protocol work to do here.
>

Maybe, maybe not. Or maybe not new protocol work, but separating which RFCs
are informative vs normative might be a big issue.

Specifically, it has to do with scope, when considering the question of
certificate validation.

The scope of the WG charter is larger than WWW use of DNS.

The related scope question is whether it is appropriate to rely exclusively
on the WebPKI rules (including trusted CAs) for validation of X.509
certificates used for DNS.

This has to do with MTI, and interoperability. It isn't going to be a
successful outcome to the WG if the result only works for browser clients
incorporating WebPKI elements (trusted CA set, and revocation via
OCSP/CRL/CT exclusively), as opposed to use of DANE (single trusted public
DNS trust anchor, and revocation by unpublishing DNSKEYs in DNS) and
possible use of non-public DNS trust anchors.

Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 15 Jan 2020 18:33:15 -0500

I don’t think it makes sense to use web PKI to establish trust, no. But to validate a certificate?  Sure. DANE is another good option, also not useful for establishing trust. 

> On Jan 15, 2020, at 18:13, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> 
>>> OK.   For an enterprise user, the easiest thing to do is just get a cert.   The IP address doesn’t matter.   If you want to use ACME, you might need to do some gymnastics, but you can make it work.   An operational document that describes how this works might be useful.  
>>  
> Maybe, maybe not. Or maybe not new protocol work, but separating which RFCs are informative vs normative might be a big issue.
> 
> Specifically, it has to do with scope, when considering the question of certificate validation.
> 
> The related scope question is whether it is appropriate to rely exclusively on the WebPKI rules (including trusted CAs) for validation of X.509 certificates used for DNS.
> 
> This has to do with MTI, and interoperability. It isn't going to be a successful outcome to the WG if the result only works for browser clients incorporating WebPKI elements (trusted CA set, and revocation via OCSP/CRL/CT exclusively), as opposed to use of DANE (single trusted public DNS trust anchor, and revocation by unpublishing DNSKEYs in DNS) and possible use of non-public DNS trust anchors.
> 
> Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 15 Jan 2020 16:08:49 -0800

On Wed, Jan 15, 2020 at 3:00 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:

> Ideally the WG product would be general enough to work for any dns
> discovery and selection situation including split dns.
>

Would it be possible to outline the interoperability problems the WG aims
to address, even if it's not in the charter itself? Opportunistic
encryption wouldn't seem to require a discovery mechanism.

thanks,
Rob

---

From: <[email-masked]>
Date: Thu, 16 Jan 2020 12:40:15 +0000

Agree

+1

-----Original Message-----
From: Add [mailto:[email-masked]] On Behalf Of Tommy Pauly
Sent: 14 January 2020 22:38
To: ADD Mailing list <[email-masked]>
Subject: [Add] Updated charter proposal for ADD

Hi all,

Best,
Tommy

Sending DNS messages over encrypted transports, as defined in DNS over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], provides benefits to the security and privacy of DNS data. Clients, such as applications and host operating systems, have started adopting these protocols to provide these user benefits.

This working group will focus on discovery and selection of DNS resolvers by DNS clients in a variety of networking environments, including public networks, private networks, and VPNs; supporting both encrypted and unencrypted resolvers.

Clients adopting encrypted DNS protocols need to determine which DNS servers support encrypted transports, and which server to use for specific queries if multiple servers are available. These decisions can vary based on the network environment, and also based on the content and purpose of the client queries.

Network operators that start offering DNS encryption on their servers also need a way to indicate this support to clients. Communicating information about resolver configuration and behavior allows clients to make more informed decisions about which DNS servers to use. For example, a resolver may be able to resolve private or local names as a split DNS server.

- define a mechanism that allows clients to discover DNS resolvers, including encrypted DNS servers, that are available to the client either on the public Internet or on private or local networks;

- define a mechanism that allows communication of DNS resolver information to clients for use in selection decisions;

- develop an informational document that describes how client applications and systems can manage selection of DNS resolvers in various network environments and use cases.

Any mechanisms that specify interactions between clients and servers must provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor.

This working group will coordinate with dnsop, doh, and dprive for any changes required in DNS protocols. It will also work with capport to ensure that solutions are applicable to captive networks.

---

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Thu, 16 Jan 2020 12:43:23 +0000

+1 but with an amendment here:

    This working group will focus on discovery *, authentication* and selection of DNS resolvers
    by DNS clients in a variety of networking environments,

This is to help mitigate the scenario of a rogue resolver in a local network.

All best,
Kevin

C2 General
From: Add <[email-masked]> On Behalf Of Andrew Campling
Sent: 15 January 2020 15:45
To: Paul Adair <[email-masked]>; Tommy Pauly <tpauly=[email-masked]>; Glenn Deen <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] Updated charter proposal for ADD

+1

Andrew

-----Original Message-----
From: Paul Adair <[email-masked]<mailto:[email-masked]>>
Sent: 15 January 2020 13:07
To: Tommy Pauly <tpauly=[email-masked]<mailto:tpauly=[email-masked]>>; ADD Mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Add] Updated charter proposal for ADD

Paul Adair
Infoblox

    Hi all,

    Best,
    Tommy

    --
    Add mailing list
    [email-masked]<mailto:[email-masked]>
    https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/add__;!!JYsgTRAg6ZQ!YAYWpqIz-5mnVKFP1uomaHnZqaaPeM7jg_t3b2JEb1RGKILDMtltv1eD68VDh3Y$>

---

From: Andrew Campling <[email-masked]>
Date: Thu, 16 Jan 2020 13:10:37 +0000

On Thurs, Jan 15, 2020 at 00:09 Rob Sayre <[email-masked]> wrote:

> Would it be possible to outline the interoperability problems the WG aims to address, even
> if it's not in the charter itself? Opportunistic encryption wouldn't seem to require a discovery
> mechanism.

Wouldn’t this be something for the WG to agree once chartered?

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jan 2020 08:17:58 -0500

> Wouldn’t this be something for the WG to agree once chartered?

Generally speaking, a tighter charter is better.   If it turns out that the WG discovers it needs to do work that is out of scope, the WG can recharter, using the new evidence that has been gathered to motivate the change.   We tend to do this poorly in the IETF, unfortunately, so participants are often unfamiliar with the process… :]

(FWIW, I happen to think that opportunistic security should be in-scope, so I’m saying this because your statement was surprising, not because I don’t want opportunistic security in the charter.)

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 17 Jan 2020 10:13:03 +0100 (CET)

> Il 14/01/2020 23:38 Tommy Pauly <tpauly=[email-masked]> ha scritto:
> 
>  
> Hi all,
> 

I am fine with this charter after removal of the "security properties" paragraph. I'm saying removal rather than rewriting because the attempts to rewrite it seem to be diverging rather than converging; if we absolutely want to write something, I'd suggest that we limit ourselves to stating that opportunistic solutions are also in scope (and that their security properties and possible use cases are to be documented, but AFAIK this is already required of any IETF document). Anything else will just reopen arguments, as it will be seen as an attempt to preempt the results of the discussion.

I'm also fine with Jari's second addition if people like it.

Personally, I would like to stress that in the end we want the user to be in control of DNS queries, as long as the user thinks to be technically savvy enough for it. Perhaps the third deliverable (the "informational document") should start from there, and describe how "users, client applications and systems" can manage their selections. But this is a minor edit, so I can also live without it.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Patrick McManus <[email-masked]>
Date: Fri, 17 Jan 2020 10:16:45 -0500

Discovery requires authentication - otherwise the encryption is just snake
oil security. everyone wants to apply policy (even if the policy is
'unfiltered') and you can't deliver that policy without authentication. And
you can't seriously offer confidentiality without authentication either.
The proposed charter is clear on this. A charter that allowed the creation
of a an unauthenticated "secure" protocol in 2020 would fail to recognize
what is possible and really ought to be irrelevant.

This, btw, does not rule out unauthenticated network mechanisms (e.g. dhcp
or pvd) as transports any more than TLS rules out unauthenticated TCP. It
just means you need to layer something else on top if you go that way (e.g.
an out of band trust root can sign a connection without caring about the
domain name as the webPKI would..)

the role of opportunistic is in ratcheting legacy systems forward - this is
a new system and should be held to a modern bar.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 17 Jan 2020 15:28:37 +0000

On Jan 17, 2020, at 7:16 AM, Patrick McManus <[email-masked]> wrote:
> 
> Discovery requires authentication - otherwise the encryption is just snake oil security. everyone wants to apply policy (even if the policy is 'unfiltered') and you can't deliver that policy without authentication. And you can't seriously offer confidentiality without authentication either. The proposed charter is clear on this. A charter that allowed the creation of a an unauthenticated "secure" protocol in 2020 would fail to recognize what is possible and really ought to be irrelevant.
> 
> This, btw, does not rule out unauthenticated network mechanisms (e.g. dhcp or pvd) as transports any more than TLS rules out unauthenticated TCP. It just means you need to layer something else on top if you go that way (e.g. an out of band trust root can sign a connection without caring about the domain name as the webPKI would...)
> 
> the role of opportunistic is in ratcheting legacy systems forward - this is a new system and should be held to a modern bar.

This proposal rules out any solution that does not mandate the client (such as an operating system) having an up-to-date set of cryptographic trust anchors (such as the web PKI or other crypto initialization by vendors). It would hobble discovery in many of the common cases that have been discussed, such as my laptop in my home using my ISP's resolver. If that type of hobbling is what this group wants, go for it, but a better approach might be allowing unauthenticated discovery that can be authenticated by those clients who want to and have the capability of doing so.

--Paul Hoffman

---

From: Patrick McManus <[email-masked]>
Date: Fri, 17 Jan 2020 12:22:25 -0500

On Fri, Jan 17, 2020 at 10:28 AM Paul Hoffman <[email-masked]>
wrote:

> This proposal rules out any solution that does not mandate the client
> (such as an operating system) having an up-to-date set of cryptographic
> trust anchors (such as the web PKI or other crypto initialization by
> vendors).

I would expect the operating system vendor to manage its trust anchors.
Using a device that is so out of date that it can't do that isn't giving
you any security - so the lack of DoH is hardly its biggest problem. But it
would be a giant problem if we built a system that undermined the
authenticated properties of DoH for the common case in order to
accommodate that.

---

From: Brian Dickson <[email-masked]>
Date: Fri, 17 Jan 2020 10:25:09 -0800

> what is possible and really ought to be irrelevant.

The scope of the proposed charter extends beyond exclusively public
resolvers and exclusively web browsers, at least as I read it currently.

For the purposes of clarity, we should be careful about the scope of
statements such as this, for which I propose some alternate wording for
what you wrote.

E.g.:
"Use of discovered resources which have globally-scoped names requires
authentication of those names as part of the protocol being used."

I.e. authentication is a "must" IFF the name is an FQDN rooted in the
public DNS tree (as served via the IANA root zone).

(This would leave open the question of authentication in other
environments, which is important for use cases that have been discussed.
Obviously any work encompassing those use cases would need to clearly
document security and privacy implications of the mechanisms used for
authentication.)

There is a  separate issue is on how identity on public FQDN certificates
is authenticated, from a protocol perspective, in terms of what is
mandatory to implement (MTI), including dependencies.

(Again, this is specifically ONLY about the authentication of resolver
identities for establishing the TLS connection from client to resolver, and
does not relate to subsequent client behavior in any other context, such as
HTTPS generally.)

This relates to establishing a privacy-protecting channel from the client
to resolver, which arguably is much broader in scope than the privacy
attributes for a TLS connection to a single end-point on the WWW.

The open question is whether WebPKI (using some set of CAs) should be MTI,
or whether use of other validation mechanisms such as DANE TLSA records
anchored at the IANA DNS Root Trust Anchor should be MTI?

As a point of relevance, IETF standards achieve the greatest degree of
interoperability when all necessary parameters are published by (or managed
by) IANA. This includes the DNS Root Trust Anchor, and all of the protocol
parameter tables.

Similarly, at least for the non-CCTLDs, ICANN has an oversight and
contractual relationship with registries, and the accreditation of
registrars.

By contrast, neither ICANN nor IANA are directly involved (at least to my
knowledge) in the management or certification of CAs. For the specific
purposes of authentication for a "secure" protocol in 2020, is it
appropriate to "bake in" the role of CAs and the CA/B to the MTI aspects of
the protocol?

I think it is something that needs to be taken into consideration in the WG
charter.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Fri, 17 Jan 2020 18:20:20 -0800

On Fri, Jan 17, 2020 at 7:28 AM Paul Hoffman <[email-masked]> wrote:

> vendors). It would hobble discovery in many of the common cases that have
> been discussed, such as my laptop in my home using my ISP's resolver. If
> that type of hobbling is what this group wants, go for it...
>

What is the improvement such a group would miss out on?

thanks,
Rob

---

From: Mohit Sethi M <[email-masked]>
Date: Tue, 21 Jan 2020 13:09:41 +0000

Hi all,

I took time to study some of the email discussion (albeit not all). I made sure to carefully read the proposed charter text written by Tommy: https://mailarchive.ietf.org/arch/msg/add/yFOsdTOf6VfNzsHPUbuFfQ5URzw.

As security folks, many of us inadvertently solve our problems by making them someone else's. A very naive example of this would be that we solved the key exchange problem of symmetric keys by making it a key distribution problem with public-key cryptography. I know that we shouldn't really discuss solutions when formulating the charter. However, I suggest that we use this opportunity to discuss the starting assumptions for a client to securely discover DNS resolvers.

Some of the proposed solutions that I looked at rely on an another trusted server in the network to provide information about DNS resolvers. And how do I discover that trusted server?, well of-course, mDNS. I would like us to solve real problems and not make cyclical dependencies (knowing that solving real problems is hard and time-consuming). I would also like to understand what type of networks are in scope? Assuming a trusted server in the local network to inform me about candidate DNS resolvers is certainly not likely in many/most home networks?

--Mohit

On 1/18/20 4:20 AM, Rob Sayre wrote:
On Fri, Jan 17, 2020 at 7:28 AM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

This proposal rules out any solution that does not mandate the client (such as an operating system) having an up-to-date set of cryptographic trust anchors (such as the web PKI or other crypto initialization by vendors). It would hobble discovery in many of the common cases that have been discussed, such as my laptop in my home using my ISP's resolver. If that type of hobbling is what this group wants, go for it...

thanks,
Rob

---

From: Mohit Sethi M <[email-masked]>
Date: Wed, 22 Jan 2020 13:50:52 +0000

My comment maybe somewhat misleading and might be interpreted as if I am against forming this working group. That is certainly not the case. I would like to see this working group formed and would be happy to review/contribute as we proceed.

As a more concrete suggestion, perhaps the following bullet in the current charter text could be better explained:

Rather than distinguishing between private/local networks vs. Internet, it could distinguish home/enterprise networks or whether infrastructure is available to aid the discovery or not. For example, some enterprise networks may have servers (such as a Windows Active Directory Domain Service) to help assist in the discovery of DNS resolvers. This would not be possible in many home networks on the other hand.

--Mohit

On 1/21/20 3:09 PM, Mohit Sethi M wrote:

Hi all,

--Mohit

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2020 09:23:34 -0500

> Rather than distinguishing between private/local networks vs. Internet, it could distinguish home/enterprise networks or whether infrastructure is available to aid the discovery or not. For example…

Practically speaking, it might help to think of this in terms of scenarios rather than types of networks.   It’s true e.g. that a corporate network may have WADDS, but it may also not.  What matters is whether it has it, not whether it is a corporate network.   It might help with clarity if we think about it this way, although I agree with your basic point.

And then what is it about WADDS that makes it able to help the client to find a secure resolver, as compared to unauthenticated DHCP?   Is it a property that is unique to WADDS, or is WADDS implementing an example of some property that other services might also be able to implement?

---

From: tirumal reddy <[email-masked]>
Date: Wed, 22 Jan 2020 21:15:01 +0530

On Wed, 22 Jan 2020 at 19:53, Ted Lemon <[email-masked]> wrote:

> On Jan 22, 2020, at 8:50 AM, Mohit Sethi M <
> mohit.m.sethi=[email-masked]> wrote:
>
> Rather than distinguishing between private/local networks vs. Internet, it
> could distinguish home/enterprise networks or whether infrastructure is
> available to aid the discovery or not. For example, some enterprise
> networks may have servers (such as a Windows Active Directory Domain
> Service) to help assist in the discovery of DNS resolvers. This would not
> be possible in many home networks on the other hand.
>
>
> Practically speaking, it might help to think of this in terms of scenarios
> rather than types of networks.   It’s true e.g. that a corporate network
> may have WADDS, but it may also not.  What matters is whether it has it,
> not whether it is a corporate network.   It might help with clarity if we
> think about it this way, although I agree with your basic point.
>
> And then what is it about WADDS that makes it able to help the client to
> find a secure resolver, as compared to unauthenticated DHCP?
>

Policies can be configured on both the OS and browsers in the endpoint via
Active directory, Discovery of DoH/DoT servers is not required. For
instance, see
https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows,
the policy can specify the Enterprise DoT/DoH server the browser should use.

The challenge is with BYOD devices or Enterprise networks that have
limited/no configuration control on endpoints.

Cheers,
-Tiru

> Is it a property that is unique to WADDS, or is WADDS implementing an
> example of some property that other services might also be able to
> implement?
>
> --
> Add mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Jan 2020 11:12:37 -0500

So you’re proposing this as a way to configure a verifiable trust relationship, right?  In this case, the trust relationship is with the active directory server and is set up by the system administrator?

For the case of BYOD, such devices should not be permitted access to the internal network. This is standard operating procedure at many enterprise sites already, and it’s just common sense. I think most devices you can get can already be set up this way, for example with a provisioning profile on iOS. 

> On Jan 22, 2020, at 10:45, tirumal reddy <[email-masked]> wrote:
> 
> 
>> And then what is it about WADDS that makes it able to help the client to find a secure resolver, as compared to unauthenticated DHCP?  
> 
> Policies can be configured on both the OS and browsers in the endpoint via Active directory, Discovery of DoH/DoT servers is not required. For instance, see https://support.mozilla.org/en-US/kb/customizing-firefox-using-group-policy-windows, the policy can specify the Enterprise DoT/DoH server the browser should use.
> 
> The challenge is with BYOD devices or Enterprise networks that have limited/no configuration control on endpoints. 
> 
> Cheers,
> -Tiru
>  
>> Is it a property that is unique to WADDS, or is WADDS implementing an example of some property that other services might also be able to implement?
>> 
>> -- 
>> Add mailing list
>> [email-masked]