Subject: [Add] ADD Calls for WF Adoption

From: "Deen, Glenn" <[email-masked]>
Date: Tue, 12 Oct 2021 15:56:39 +0000

Hi ADD,

I wanted to bring to the ADD Group’s attention that 2 documents have entered into CALL for WG Adoption in the last couple of days:

  1.  Draft-reddy-add-enterprise-split-dns   https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/

  1.  Draft-boucadair-add-deployment-considerations https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/

Both drafts are material that has had good discussion both on list and during past ADD meetings so please consult the archive and meeting minutes, especially IETF110 and IETF111 if you need additional background.

Both are in a 2 week call for adoption, with the first ending on Oct 26,2021 and the second on Oct 27,2021.

Please respond on list with comments on these calls.

Regards
Glenn

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Oct 2021 17:35:36 -0400 (EDT)

>  1. Draft-reddy-add-enterprise-split-dns   https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/

[ I will review the second document soon ]

I still have issues with the split dns document unfortunately. I still 
feel that it is designed the standard use case to work, without enough 
consideration for networks that are not strong enterprise IT based, or the 
malicious use of this feature.

The core problem is and has always remained the security of any of the
ADD documents. There is a battle between "trust the network for DNS"
vs "never trust the network for DNS". This disagreement of views is
not going away. At best, it can be clearly demarcated by Enterprise
requirements. But those tend to come from Enterprise Provisioning. While
I see value at standardizing that, I don't feel ADD is the right way
of doing this based on the current documents.

This document can say that this is for "enterprise" networks, but an 
enduser does not know when it is connecting to an enterprise network or 
not. Even if it does, it is unclear why the user should trust a list of 
domains to "give away" to the local resolver. Should a Google Wifi at a 
Starbucks be able to redirect gmail.com ? Should "coffee.com" be able
to be redirected by a Starbucks Wifi? Or by Java House Inc ? Who even
is coffee.com? Can humans even made these kind of decisions? And if
humans can't, do we think we can teach algorithms this ?

These problems are similar to IKEv2 split DNS (RFC 8598, of which I am a
co-author) but in that case, there is an explicitly configured trust
relationship (the VPN profile on the mobile device). Even then, the
list of domains that could be redirected was _greatly_ restricted due
to browser vendors being afraid of non-enterprise VPNs (eg public VPN
services) being able to override DNS/DNSSEC/TLSA records, overriding
the WebPKI. This document has all of the same problems, and it is
unclear to me whether the listed RFCs for obtaining various bits of
information - via the public internet - is going to securely convey
that information.

It seems a PvD ID is expressed as an FQDN, but before one client can
decide to redirect a domain to an internal DNS server, it has to DNS
lookup the PvD ID FQDN. Therefor it follows this cannot be in the same
domain. So nohats.ca cannot put their pvd at pvd.nohats.ca. Then how
can one do a trusted PvD lookup? Maybe I missed this in some of the
other drafts and RFCs listed in this draft?

It also seems a redirected domain cannot provide an alternative DNSSEC
trust anchor via PvD ? This would prevent split DNS domains from
effectively using DNSSEC in the split non-world view, OR the internal
zones and worldview zones are required to use the same DNSSEC KSK/DS
as to not break DNSSEC validation on the client. I believe that if you
want to securely redirect DNSSEC protected queries to an alternative
DNS server, the solution should be able to support DNSSEC protected
queries from the split network.

Section 4.1:

 	To comply with [RFC2826] the split-horizon DNS zone must either not
 	exist in the global DNS hierarchy or must be authoritatively
 	delegated to the split-horizon DNS server to answer.

I am unsure how this "authoritatively delegated to the split-horizon DNS
server" works? Unless it means "single public reachable DNS server with
bind views". I don't think these two methods would cover most of the
split DNS zones currently deployed. I think RFC2826's advise in practise
is a ship that sailed a long time ago. This is again an important issue,
because it is the base of trust going forward. The client will receives
answers it has to trust, but I don't see the full verifiable linked chain
clearly. I am not sure if that is due to the document text or my 
understanding of it.

 	The client sends an NS query for the domain in DnsZones.  This
 	query MUST only be sent over encrypted DNS session to a public
 	resolver that is configured independently or to a network-
 	designated resolver whose response will be validated using DNSSEC
 	as described in [RFC6698].

I have strong objections to treating DNSSEC validation and "outsourced
DNS validation over secure transport" as equivalent. Transport security
is not data origin protection. This statement has the underlying claim
that the outsourced DNS query to a public DNS server over TLS is
equivalent to a DNSSEC protected query (over TLS or not). It is not
equivalent. I have concerns about TRR and ADD type DNS resolvers getting 
mandated by nation states as internet entry points, and ADD really helps
building such a censorship infrastructure. One MUST be able to require
DNSSEC to ensure domain owners keep control of their domain and not lose
it to a nation state with bad intensions.

 	The client checks that the NS RRset matches any one of the ADN of
 	the discovered network-designated encrypted DNS resolvers.

Which NS RRset is it supposed to check? The RRset at the parent
(unsigned!) or at the child (validatable). Current practise already
sees so many mismatches between these two (called lame delegations)
that I think this cannot be used by the ADD client to determine
applicability unless there is a Section of test clarifying what it
should do with respect to different NS RRsets.

 	If the match succeeds, the client can then establish a secure
 	connection to that network-designated resolver and validates
 	its certificate.

I guess it cannot build a secure connection _until_ it has validated
its certificate? There are subtle implications here, as in the
connection cannot be blindly used, it must first go from unvalidated
to validated before it is available.

 	As an exception to this rule, the client need not perform the
 	above validation for domains reserved for special use [RFC6761]
 	or [RFC6762] such as ".home.arpa" or ".local".

What about those split DNS worlds that use .local locally. There are
many. Should all of them skip validation? That is a security issue
that should be addressed in a better way.

    For example, if in a network the private domain names are defined
    under "internal.corp1.example.com".  The DnsZones PvD Key would
    indicate that "*.internal.corp1.example.com" are private domain
    names.  The client can trigger a NS query of
    "internal.corp1.example.com" and the NS RRset returns that the
    nameserver is "ns1.corp2.example.com".  The client would then connect
    to the network-designated encrypted resolver whose name is
    "ns1.corp2.example.com", authenticate it using server certificate
    validation in TLS handshake, and use it for resolving the domains in
    the subtree of "*.internal.corp1.example.com".

It is unclear to me where the PVD Key (PVD ID, aka FQDN) for this domain
should be "found" ? See my comment above? It cannot be on the internal
resolver, that has not been approved yet as valid. Should it be done on
the public one? But then all split zones need to coordinate (eg all
*.starbucks.com need to link their coffeeshops to the same public PVD
info?). I don't fully understand the bootstrap here, and cannot determine
its security.

Security Considerations section:

    As an additional precaution, clients may want to preconfigure global
    domains for TLDs and Second-Level Domains (SLDs) to prevent malicious
    DNS redirections for well-known domains.

This seems like a really big deal. It kind of says this mechanism cannot
be fully trusted. Preconfiguration of "well-known domains" in internet
protocols is very damaging to the decentralized nature of the internet -
it creates first and second class citizens/domains. If the draft cannot
address this problem, I would be tempted to look for alternative solutions
that stand on their own protocol without hardcoded lists.

I think this document is using "enterprise deployment" in too easy a
way. WPA2 Enterprise is deployed by coffee shops, so the protocol
specifications says nothing about the how the protocol will be used.
So to me, this protocol is "Access Point split DNS", and I have to
figure out if the access point is trusted or not. It seems that the
validation of this depends strongly on being able to reach public DNS
servers, which is often not the case. For example ISP redirectin of
8.8.8.8 to their own servers, country level blocking of public DNS
for censorship reasons, etc.

I am still not convinced that any client (browser) should ever enable
any of this (ADD) for their own security. In fact, I would almost argue 
that setting up an IKEv2 VPN _just_ for configuring DNS using RFC 8598 
would be a better solution. It would require an explicit trust 
relationship between client and network, installed with consent of and by 
the enduser, and would be limited to the security considerations of RFC 
8598. And it would support internal zones with their own DNSSEC keys 
different from the public zones. Of course, I don't want to securely
provision my phone or laptop for all the coffeeshops brands in the world,
so we need something better. But so far, I don't think this draft is
providing me with a strong alternative solution for reconfiguring part
of my DNS.

Paul

---

From: tirumal reddy <[email-masked]>
Date: Thu, 14 Oct 2021 15:24:37 +0530

Hi Paul,

Thanks for the review. The split-horizon DNS configuration is not specific
to Enterprise networks and is applicable to other types of networks
offering private domains.  The draft does not make any assumptions whether
the network is Enterprise or not based on the WiFi authentication mechanism.

Please see inline

On Wed, 13 Oct 2021 at 03:06, Paul Wouters <paul.wouters=
[email-masked]> wrote:

> > I wanted to bring to the ADD Group’s attention that 2 documents have
> entered into CALL for WG Adoption in the last couple of days:
> >
> >  1. Draft-reddy-add-enterprise-split-dns
> https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
>

As I have mentioned previously, the proposed mechanism in the draft is not
specific to Enterprise networks.

> humans can't, do we think we can teach algorithms this ?

The network-designated resolver must prove authority over the domains as
discussed in
https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-06#section-4.1,
otherwise, the client will not use the network-designated resolver to
resolve the domains in the "dnsZones" key. Most importantly, the mechanism
proposed in the draft does not require any end-user intervention to
determine authority over the domains.

> other drafts and RFCs listed in this draft?

Retrieving the additional PvD information using an HTTPS server is
discussed in  https://datatracker.ietf.org/doc/html/rfc8801#section-4.1.

> is not data origin protection.

Good point, we will update the draft to clarify that a DNSSEC validating
client will apply the same validation policy to the NS query as it does to
other queries.

This statement has the underlying claim
> building such a censorship infrastructure.

The client would use the proposed mechanism only if it is configured to use
a DNS resolver not signalled by the network (e.g., the endpoint is
configured to use VPN or a public resolver).  If the client is using
DNR/DDR to discover and use the network-designated resolvers, it does not
have to use this draft and the split-horizon domains will be resolved by
the network-designated DNS server.

> One MUST be able to require

If the client is using a public resolver, it is anyway receiving all the
queries from the endpoint including the queries for private domains and the
bad public resolver can do a lot more damage than lying about the
non-existence of a domain.

> should do with respect to different NS RRsets.

The client will have to check the NS RRset at the child and not at the
parent level. We will update the draft for better clarity.

> to validated before it is available.

Sure, we will fix the above line as follows:

If the match succeeds, the client establishes a TLS connection to that
network-designated resolver and validates the server certificate exchanged
during the TLS handshake.

> that should be addressed in a better way.

I don't get the above comment, please elaborate on the need to perform the
validation for .local domains.

> that stand on their own protocol without hardcoded lists.

No, the mechanism discussed in Section 4.1 is required to determine if the
network-designated encrypted resolver is authoritative over the domain in
DnsZones. The well-known domains are only used as a first line of defense
to detect if the network is lying.

Cheers,

-Tiru

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

---

From: Paul Wouters <[email-masked]>
Date: Thu, 14 Oct 2021 13:18:23 -0400 (EDT)

On Thu, 14 Oct 2021, tirumal reddy wrote:

> Thanks for the review. The split-horizon DNS configuration is not specific to Enterprise networks and is applicable to other types of networks offering
> private domains.  The draft does not make any assumptions whether the network is Enterprise or not based on the WiFi authentication mechanism.

That is not the traditional way of defining an "enterprise network".
Also, the document _does_ define it:

    The term "enterprise network" in this document extends to a wide
    variety of deployment scenarios.  For example, an "enterprise" can be
    a Small Office, Home Office or Corporation.

It is not at all obvious that we can encounter this protocol at
coffeeshop and hotel wifis, which have a strongly different security
context from corporate enterprises (small or home or large)

I can ignore the "enterprise" in the draft name, but not the definition
in the document with the security aspects of the protocol. So in that
way, my raised issues still apply and have not been addressed.

> The network-designated resolver must prove authority over the domains as discussed in 
> https://datatracker.ietf.org/doc/html/draft-reddy-add-enterprise-split-dns-06#section-4.1, otherwise, the client will not use the network-designated
> resolver to resolve the domains in the "dnsZones" key. Most importantly, the mechanism proposed in the draft does not require any end-user intervention to

Can you please give me (or better yet, in the document) and complete
example of the queries and responses sent? Because I still feel there
is a chicken and egg problem here. The location of PvD related to the
domain names in particular is what I don't understand.

> Retrieving the additional PvD information using an HTTPS server is discussed in  https://datatracker.ietf.org/doc/html/rfc8801#section-4.1.  

I read that part, but it does not explain it to me well enough to
understand:

    When the H-flag of the PvD Option is set, hosts MAY attempt to
    retrieve the PvD Additional Information associated with a given PvD
    by performing an HTTP-over-TLS [RFC2818] GET query to "https://<PvD-
    ID>/.well-known/pvd".  Inversely, hosts MUST NOT do so whenever the
    H-flag is not set.

What is the relationship between PvD-ID as FQDN and the domain names
(plural!) that I'm asking authentication of? Can I send a PVD-ID H-flag
pointing to pvd.nohats.ca? That would list "gmail.com" ? Please clarify
the relationship between the internet-reachable PvD domain name and the
target list of domain names the network wants to take over. Then also
tell me how that would work for 50000 starbucks wifi networks?

>       clearly. I am not sure if that is due to the document text or my

You did not answer this question.

> Good point, we will update the draft to clarify that a DNSSEC validating client will apply the same validation policy to the NS query as it does to other
> queries. 

that would improve things, but still leave this authentication method
between starbucks consumer and starbucks provider to whatever thid party
DNS server the consumer has installed, and requires that this third
party DNS is reachable. If it is not reachable (eg lets say DoH and DoT
is blocked) then this requrement fails. What does a client then do? Use
regular port 53 from the local network? Refuse to send the query and fail?
If the latter, then I can censor newyorktimes.com simply by adding it to
my dnsZones and blocking all known DoT/DoH servers. In other words, this
part of the protcol implies to do something security related, but it
does not actually seem to add security AND it potentially adds a denial of
service vector.

> The client would use the proposed mechanism only if it is configured to use a DNS resolver not signalled by the network (e.g., the endpoint is configured
> to use VPN or a public resolver).  If the client is using DNR/DDR to discover and use the network-designated resolvers, it does not have to use this draft
> and the split-horizon domains will be resolved by the network-designated DNS server.

We are saying the same thing. Imagine Badcountry says "configure TRR to
IP a.b.c.d" or else. And now this whole protocol is triggered with their
potential impact with the (wrong) assumption that this is something the
user opted in to but are actually forced in to. Our goal should be to
make this as least attrictive to censors as possible.

> If the client is using a public resolver, it is anyway receiving all the queries from the endpoint including the queries for private domains and the bad
> public resolver can do a lot more damage than lying about the non-existence of a domain. 

It is not the public resolver that is the issue here, but the local one.
Say my company uses DNSSEC to protect "nohats.ca" and now I'm going to
the office, and connect to the split-dns. I wouldn't want to degrade the
security to non-dnssec just because I cannot get the split DNS trust
anchor for "nohats.ca" within this office in Toronto (which on top of
things might also be differet from the split DNS trust anchor in use by
my office in Helsinki). How can I get DNSSEC to work for "nohats.ca" in
the split view DNS at various offices ? I see no capability in the
protocol for this, so using this protocol always causes a downgrade from
DNSSEC to non-DNSSEC.

> The client will have to check the NS RRset at the child and not at the parent level. We will update the draft for better clarity.

So all offices of "nohats.ca" worldwide have to use the same single "discovered
network-designated encrypted DNS resolvers"? Because they will all get
the same answer from public DNS ? This would be hard to impossible to
manage for global companies with different IT departments in each
country or city.

> If the match succeeds, the client establishes a TLS connection to that network-designated resolver and validates the server certificate exchanged during
> the TLS handshake. 

How does it validate the TLS certificate ? I don't think TLSA because
again that would be available only on 1 version in the world view, but
ns.toronto.nohats.ca might not exist in the worldview if
toronto.nohats.ca is the split dns name to begin with ? And the network
is likely on private IP space and we can't look up things there? That
leaves webpki but how are those going to validate private IP or
non-public names ?

> I don't get the above comment, please elaborate on the need to perform the validation for .local domains. 

I believe it was Microsoft who recommended companies use ".local" or
".corp" for their internal domain name. This document saying to skip
validation on those means these names cannot be securely used for split
DNS.

>       info?). I don't fully understand the bootstrap here, and cannot determine

You did not answer this question, which is my biggest question actually
as the mapping between PvD domain and dnsZones entry is what I don't
understand.

> No, the mechanism discussed in Section 4.1 is required to determine if the network-designated encrypted resolver is authoritative over the domain in
> DnsZones. The well-known domains are only used as a first line of defense to detect if the network is lying.  

Either your method is secure, and this "additional precaution" is not
providing security and should be removed, or it does provide some
security, in which it is hiding a fundamental flaw in the security
properties of this protocol.

Paul

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 15 Oct 2021 12:18:26 +1100

Hi,  I've now read both of these.  I've also refreshed myself on the SVCB work, the DNS SVCB draft, the DDR draft, the DNR draft, and DNS over QUIC for good measure.

(I have to say that this is starting to get a little out of hand for those of us with limited time to participate.  I'm reminded of how high energy groups can appear to be denial of service attacks from the outside.  Having perpetrated several of those myself, I know there is no easy answer.)

> https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/

I've not formed an opinion on this work.  I've read it, I can see the use case, but I'm still uncertain about the mechanisms being proposed.  The use of PvD seems fine. But the authorization piece is not clear.  It seems to depend on secure connections to an authoritative, except that this is for a stub resolver, but maybe I didn't take enough time to work through the entire process or think about alternatives.
 
>  1. Draft-boucadair-add-deployment-considerations 
> https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/

After reading this and DNR together, I think that DNR does not need this additional context.  It's a relatively clear and focused document and the calls out to this document could easily be cut without loss of clarity.

There is a lot in this draft to get wrong and while I didn't read closely enough to point to specific problems, it seemed quite superficial in its treatment of different network topologies.  As such, I doubt that it adds much clarity regarding how the protocol might be deployed.

I think we should regard this as a useful contribution to the discussion, but I don't think that it needs to be published.  We should (collectively) spend our efforts on getting the core documents improved.

---

From: Tommy Pauly <[email-masked]>
Date: Fri, 15 Oct 2021 15:21:25 -0700

I agree with the sentiments being expressed on list that this document isn’t quite ready to adopt in this form.

There’s something here, but the problem being tackled here is larger than enterprise networks, and even split-DNS local network configurations. The use case for enterprise networks is a valid driver of the problem, but I don’t think we can solve it without addressing the problem of proving a relationship between a set of domains and a Provisioning Domain (where that domain can imply a set of DNS resolvers and even network paths that are correct to use). VPNs do solve this nicely today, but we are missing the mechanism to this in a trusted way without a VPN or managed configuration.

The core idea about identifying that a resolver is the “right one” was also one of the goals the work around our “adaptive DNS privacy” was centered around (https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery-01#section-3.2 <https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery-01#section-3.2>). In that, the client would have discovery using PvDs, and could confirm the designation of a resolver by the domain owner by looking at a web-fetched PvD file off of the apex domain for the zone. That was a different use case, but I think it shows that the space of solutions we can use to associate domains is broad.

Thanks,
Tommy

> On Oct 14, 2021, at 10:18 AM, Paul Wouters <paul.wouters=[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 15 Oct 2021 16:01:22 -0700

I'm actually trying to work through the logic of this. As I understand
it, suppose that I control example.com and I want to have it be split,
I would do two things:

* Publish something like the following in the dnsZones key.

  { "identifier": "ns1.example.org", "dnsZones" : ["example.com"]}

* Publish an NS record for "example.com" pointing to "ns1.example.org"

Note that the text doesn't seem to say that the "identifier" field
reflects the server, so I'm kind of guessing here.

A client which is conformant to this draft:

1. Looks up the NS record for example.com using a public
   resolver (step 1)
2. Sees that it matches "ns1.example.org" (step 2A)
3. Connects to ns1.example.org 2(B). If that succeeds, then it
   uses ns1.example.org to resolve example.com.

Do I have this right?

Assuming this is so, how does the client learn the IP address for
ns1.example.org? Ordinarily this would be a glue record when it
retrieved the NS records. Is that what happens here?

I've got some more questions, but I'll stop now and get back to
them once I understand if this is right.

-Ekr

On Fri, Oct 15, 2021 at 3:21 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> There’s something here, but the problem being tackled here is larger than
> enterprise networks, and even split-DNS local network configurations. The
> use case for enterprise networks is a valid driver of the problem, but I
> don’t think we can solve it without addressing the problem of proving a
> relationship between a set of domains and a Provisioning Domain (where that
> domain can imply a set of DNS resolvers and even network paths that are
> correct to use). VPNs do solve this nicely today, but we are missing the
> mechanism to this in a trusted way without a VPN or managed configuration.
>
> The core idea about identifying that a resolver is the “right one” was
> also one of the goals the work around our “adaptive DNS privacy” was
> centered around (
> https://datatracker.ietf.org/doc/html/draft-pauly-add-resolver-discovery-01#section-3.2).
> In that, the client would have discovery using PvDs, and could confirm the
> designation of a resolver by the domain owner by looking at a web-fetched
> PvD file off of the apex domain for the zone. That was a different use
> case, but I think it shows that the space of solutions we can use to
> associate domains is broad.
>
> Thanks,
> Tommy
>
> On Oct 14, 2021, at 10:18 AM, Paul Wouters <
> paul.wouters=[email-masked]> wrote:
>
> to Enterprise networks and is applicable to other types of networks offering
> private domains.  The draft does not make any assumptions whether the
> network is Enterprise or not based on the WiFi authentication mechanism.
>
>
> otherwise, the client will not use the network-designated
> resolver to resolve the domains in the "dnsZones" key. Most importantly,
> the mechanism proposed in the draft does not require any end-user
> intervention to
> other
> The client would use the proposed mechanism only if it is configured to
> use a DNS resolver not signalled by the network (e.g., the endpoint is
> configured
> to use VPN or a public resolver).  If the client is using DNR/DDR to
> discover and use the network-designated resolvers, it does not have to use
> this draft
> bad
> during

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 19:11:11 -0400

I am not sure what to think about enterprise-split-dns.

I guess if ADD is going to continue down the route of creating yet more ways
to signal to the "stub" resolver that it needs more really complex policy,
then this document is the way to do it.

==== you probably shouldn't read further

rot13.

Nf fbzrbar jub ohvyg naq fbyq sverjnyyf va gur rneyl 1990f juvpu pbasvtherq
fcyvg-ubevmba QAF ol qrsnhyg, V srry znal ertergf.  Vg jnf gur jebat
fbyhgvba gura, ohg gung jnf uneq gb frr gung.  Abj, tvira QAFFRP, ICAf bs nyy
xvaqf, naq abj rapelcgrq erdhrfg, vg'f pyrneyl gur jebat nafjre.

Pna'g jr tb onpx, naq whfg chg n erphefvir anzr freire va rirel pyvrag?
Tvira gur pbqr fvmr bs zbfg oebjfref, univat na vagreany erphefvir anzrfreire
frrzf yvxr n ernyyl fznyy pbfg.  yvohaobhaq vs lbh jnag.

Gura, "pbec.rknzcyr.pbz" whfg pbzrf jvgu fbzr AF (naq QF!) erpbeqf gung cbvag
gb na nhgubevgngvir anzr freire gung jba'g nafjre dhrevrf sebz bhgfvqr gur
ragrecevfr.  Pyvragf jvgu ICAf znxr dhrevrf gb gubfr nqqerffrf, xvpx gur ICA,
naq abobql unf gb qb nal zntvp.    Hfr QbG, QbU, QbD... jungrire.

Arrq obex gur nafjref?    Gura whfg TebhcCbyvpl gur GYF Pregvsvpngr sbe gur QAF
ybbxhcf, gur fnzr nf lbh'q qb sbe gur UGGCF.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Michael Richardson <[email-masked]>
Date: Sat, 16 Oct 2021 19:14:08 -0400

Martin Thomson <[email-masked]> wrote:
    > I've not formed an opinion on this work.  I've read it, I can see the
    > use case, but I'm still uncertain about the mechanisms being proposed.
    > The use of PvD seems fine. But the authorization piece is not clear.
    > It seems to depend on secure connections to an authoritative, except
    > that this is for a stub resolver, but maybe I didn't take enough time
    > to work through the entire process or think about alternatives.

All of the work in this WG is way more complex than a Stub Resolver.

It's time to stop calling it that.  It needs a new name.
It's no longer the same code base.
We aren't going to interoperate with legacy code.

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 16 Oct 2021 19:25:36 -0400

I've read this document a couple of times, and while I feel I understand
the problem they are attempting to solve, I feel it needs more work before
it can be adopted.   Also, Mr Wouters raised some valid questions that were
not all answered.

tim

---

From: Steffen Nurpmeso <[email-masked]>
Date: Sun, 17 Oct 2021 01:50:12 +0200

Michael Richardson wrote in
 <28275.1634426048@localhost>:
 |
 |Martin Thomson <[email-masked]> wrote:
 |> I've not formed an opinion on this work.  I've read it, I can see the
 |> use case, but I'm still uncertain about the mechanisms being proposed.
 |> The use of PvD seems fine. But the authorization piece is not clear.
 |> It seems to depend on secure connections to an authoritative, except
 |> that this is for a stub resolver, but maybe I didn't take enough time
 |> to work through the entire process or think about alternatives.
 |
 |All of the work in this WG is way more complex than a Stub Resolver.

You need to add a domain name filter on top of it to be able to
use specific upstreams for specific domains.

 |It's time to stop calling it that.  It needs a new name.

Stub resolver 2.0.

 |It's no longer the same code base.

You do a SVCB to dynamically fetch upstream server names instead
of using config-files, built-ins or falling back to root servers
if unavailable.  Or add it on top.

You prefilter used upstream servers depending on names to look up.

 |We aren't going to interoperate with legacy code.

I have to admit i stopped reading the rich text mails here a long
time ago, but i had read the first draft once it came up.
Please show patience if i have missed something important.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 11:50:32 +0530

Hi Tommy,

Please see inline

On Sat, 16 Oct 2021 at 03:51, Tommy Pauly <[email-masked]> wrote:

> correct to use).

Yes, the problem is applicable to any private network including enterprise.
For instance, some mobile ISPs operate private networks for their mobile
subscribers to view and pay their bill, increase their data cap, or adjust
other aspects of their service.

VPNs do solve this nicely today, but we are missing the mechanism to this
> in a trusted way without a VPN or managed configuration.
>

VPNs are straightforward because of the existing pre-configuration on the
VPN client to authenticate the VPN server and secure signalling (e.g,
IKEv2) to convey the split-horizon DNS configuration. The VPN service
provider can still lie and the proposed mechanism in Section 4.1 of the
draft can help the client to determine if the VPN service provider is
authoritative over the INTERNAL_DNS_DOMAIN domains.

> associate domains is broad.

The draft is also using PvD to convey the split-horizon DNS configuration
to the endpoint and the network has to prove its authority over the domains.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 11:54:59 +0530

Hi Eric,

Please see inline

> reflects the server, so I'm kind of guessing here.

The "identifier" field should match the PVD FQDN conveyed to the endpoint
in the PVD RA option (see
https://datatracker.ietf.org/doc/html/rfc8801#section-3.1). The client
establishes HTTPS connection to the PVD FQDN to retrieve PVD additional
information including dnsZones and prefixes.

The client will learn the network-designated resolver "ns1.example.o
<http://ns1.example.com>rg" using the RA option defined in
draft-ietf-add-dnr.

>    uses ns1.example.org to resolve example.com.

Yes.

> retrieved the NS records. Is that what happens here?

The client will learn the IP addresses of ns1.example.org using the RA
option defined in draft-ietf-add-dnr.

-Tiru

>> Thanks for the review. The split-horizon DNS configuration is not
>> specific to Enterprise networks and is applicable to other types of
>> networks offering
>> No, the mechanism discussed in Section 4.1 is required to determine if
>> the network-designated encrypted resolver is authoritative over the domain
>> in

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 12:12:00 +0530

Hi Paul,

Please see inline

> way, my raised issues still apply and have not been addressed.

The "Enterprise" terminology was left over text from previous versions of
the draft addressing only enterprise specific deployments. Based on
the discussions and feedback from the WG, the draft has been updated
to make it applicable to any type of private networks offering
split-horizon DNS configuration.

We will remove the text from the Terminology section.

> domain names in particular is what I don't understand.

You may want to look into the example given in the last paragraph of
Section 4.1. In that example, the PVD FQDN can be "internal
.corp1.example.com".

> pointing to pvd.nohats.ca? That would list "gmail.com" ?

The PVD FQDN conveyed in the PVD RA option and domain names in DNSZones
could be hosted by the same entity. The HTTPS connection to the PVD FQDN
would use PKIX validation to check if the PVD FQDN matches the DNS-ID in
the server certificate (discussed in Section 4.1 of RFC8801) and match the
"identifier" field in the PvD Additional Information JSON object.

> Please clarify

The additional PVD information can provide the local network information to
the endpoints (see the "prefixes" field discussed in RFC8801).  The PVD
FQDN can be a HTTPS server located in each Starbucks WiFi network to
provide additional PvD information specific to the attached network.

> You did not answer this question.

RFC2826 does not preclude private networks from operating their own private
name spaces  and https://datatracker.ietf.org/doc/html/rfc6950#section-4
provides more details to complement RFC2826 that in a split horizon, an
authoritative server gives different responses to queries from the public
Internet than they do to internal resolvers.

> does not actually seem to add security AND it potentially adds a denial of

If a network wants to block newyorktimes.com, it can simply block access to
all well-known DoH/DoT servers and if the client has enabled a strict
privacy profile, it will not have internet access. The user has two
choices: either use a different network or switch-over to the
network-designated resolver.

The presence of draft-reddy-add-enterprise-split-dns does not make it
easier to block a domain. Domain blocks have to block resolution of the
domain, by any means.  Which would include blocking DNS over Twitter,
https://twitter.com/1111resolver, and DoH/DoT/DoQ and blocking
https://mxtoolbox.com/SuperTool.aspx, and, and .... really, everything.

> make this as least attrictive to censors as possible.

If the BadCountry wants, it can mandate endpoints to install BadCountry
root CA, spyware, malware etc. Please explain how this draft will help an
attacker to configure a TRR.

Most importantly, if BadCountry manages to configure its TRR in the
endpoint, why is this draft required to enforce censoring ?

> protocol for this, so using this protocol always causes a downgrade from

DNSSEC validation will fail anyway if the endpoint decides to use the
network-designated resolver. How is it working for BYOD devices today
without MDM or configuration profile ?

> manage for global companies with different IT departments in each

Good point, the problem can be addressed if the discovered
network-designated encrypted DNS resolver is a sub-domain of the NS RRset
and if the server certificate includes both the domains.

> leaves webpki but how are those going to validate private IP or

PKIX authentication will be used by the client to authenticate
the network-designated resolver.

> validation on those means these names cannot be securely used for split

Browsers configured to use a TRR do not use DoH for ".local" domains by
default (see https://wiki.mozilla.org/Trusted_Recursive_Resolver).  What is
the need to perform validation for ".local" domains and how do you propose
to perform validation for ".local" domains ?

> > DnsZones. The well-known domains are only used as a first line of
> defense to detect if the network is lying.
>

The additional precaution is only added to speed-up the process of
identifying if the network is lying.
We will update the draft to say the "additional precaution" is optional and
even if the well-known domain check fails to identify the network is lying,
the mechanism discussed in Section 4.1 is mandatory to identify if the
network is lying.

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 12:16:45 +0530

> then this document is the way to do it.

The complexity comes from the fact that endpoints do not use
network-designated resolvers for various reasons and the endpoints
are unable to or properly resolve split-horizon DNS domains.

-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Mon, 18 Oct 2021 13:08:37 +0530

On Sun, 17 Oct 2021 at 04:56, Tim Wicinski <[email-masked]> wrote:

> it can be adopted.

The draft is a starting point and we invite others to share whether the
proposed mechanism works for their specific environments.

>  Also, Mr Wouters raised some valid questions that were not all answered.
>

It is the holiday season in India (
https://en.wikipedia.org/wiki/Vijayadashami) and I am trying my best to
respond to the comments from the WG :)

Cheers,
-Tiru

---

From: Michael Richardson <[email-masked]>
Date: Mon, 18 Oct 2021 09:15:00 -0400

> are unable to or properly resolve split-horizon DNS domains.

All the complexity goes away if endpoints have recursive resolvers, and
enterprises use restricted-view subdomains ("corp.example.com").
In that context, ADD is about finding a local secure "forwarders"

The problem we have is that IETF has never defined Split-Horizon DNS.
(AFAIK)

It's just happened.     Now, this document is proposing changes to an
architecture which was never previously well defined.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Oct 2021 15:22:21 -0400

On Oct 18, 2021, at 02:42, tirumal reddy <[email-masked]> wrote:
> 
> 
> The "Enterprise" terminology was left over text from previous versions of the draft addressing only enterprise specific deployments. Based on the discussions and feedback from the WG, the draft has been updated to make it applicable to any type of private networks offering split-horizon DNS configuration.
> 

Okay.

> You may want to look into the example given in the last paragraph of Section 4.1. In that example, the PVD FQDN can be "internal.corp1.example.com".

But this is the problem I don’t understand. If my internal network is corp.example.com, I can’t have my pvd fqdn within corp.example.com because the internal zone is not in the public dns, and your draft says to find the pvd in public dns. So there is no straight mapping of domains and then we are back at the security issue of one domain (pvd) vouching for another domain with no verifiable authorization of such a domain.

> The PVD FQDN conveyed in the PVD RA option and domain names in DNSZones could be hosted by the same entity. The HTTPS connection to the PVD FQDN would use PKIX validation to check if the PVD FQDN matches the DNS-ID in the server certificate (discussed in Section 4.1 of RFC8801) and match the "identifier" field in the PvD Additional Information JSON object. 

Sorry, I don’t understand the security flow.
If I am the owner of example.com and I want a split dns for corp.example.com, which DNS records do I need, what dnsZones and what pvd fqdn?  Note that corp.example.org does not exist in the public dns.

> 
> If a network wants to block newyorktimes.com, it can simply block access to all well-known DoH/DoT servers and if the client has enabled a strict privacy profile, it will not have internet access. The user has two choices: either use a different network or switch-over to the network-designated resolver. 

A user has only a choice if it is presented with the domain list. Will that be part of the protocol ? If not, how do you prevent abuse (eg Hilton wifi blocking Priceline) using this method. That is irrespective of wether other blocking methods exist.

> The presence of draft-reddy-add-enterprise-split-dns does not make it easier to block a domain. Domain blocks have to block resolution of the domain, by any means.  Which would include blocking DNS over Twitter, https://twitter.com/1111resolver, and DoH/DoT/DoQ and blocking https://mxtoolbox.com/SuperTool.aspx, and, and .... really, everything.
> 

If a user connects and automatically processed dnsZones then I think it does. Perhaps I will understand if you show me the full process for corp.example.org.

> If the BadCountry wants, it can mandate endpoints to install BadCountry root CA, spyware, malware etc. Please explain how this draft will help an attacker to configure a TRR. 
> 
> Most importantly, if BadCountry manages to configure its TRR in the endpoint, why is this draft required to enforce censoring ?

Currently, the network cannot tell me to send queries for certain domains to special servers. This draft changes that and I still do not understand the security mechanism that defends against this feature being abused.

>> 
>> > I see no capability in the
> DNSSEC validation will fail anyway if the endpoint decides to use the network-designated resolver. How is it working for BYOD devices today without MDM or configuration profile ?

the IKEv2 protocol can convey DNSKEY records to use on the private view. It’s part of the IKEv2 split DNS RFC.

> Good point, the problem can be addressed if the discovered network-designated encrypted DNS resolver is a sub-domain of the NS RRset and if the server certificate includes both the domains. 

That still requires worldwide offices to work together on LAN deployment parameters. That’s not easy or foolproof, and could possibly lead to DNS resolution failures.

> PKIX authentication will be used by the client to authenticate the network-designated resolver. 

How will you get PKIX certificates for non-public DNS names to comply with ACME requests and CT requirements ?

> Browsers configured to use a TRR do not use DoH for ".local" domains by default (see https://wiki.mozilla.org/Trusted_Recursive_Resolver).  What is the need to perform validation for ".local" domains and how do you propose to perform validation for ".local" domains ?

So what about .corp or .internal or .lan ? It’s the same problem. 

>> as the mapping between PvD domain and dnsZones entry is what I don't

I still don’t have an answer that allows me to follow the authorization and authentication steps of this protocol.

> The additional precaution is only added to speed-up the process of identifying if the network is lying. 
> We will update the draft to say the "additional precaution" is optional and even if the well-known domain check fails to identify the network is lying, the mechanism discussed in Section 4.1 is mandatory to identify if the network is lying.

Once the core protocol is clear, we can revisit the security considerations section. But this document makes core changes to security models by carving into the public DNS, and it requires careful consideration and mitigation in the protocol that’s more than a security consideration section.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Oct 2021 22:07:27 -0400 (EDT)

On Mon, 18 Oct 2021, tirumal reddy wrote:

> The complexity comes from the fact that endpoints do not use network-designated resolvers for various reasons and the endpoints are unable
> to or properly resolve split-horizon DNS domains.

One could also reverse this. The complexity comes from networks wanting
to take over a list of domains without a clear mandate of the endpoints
via proper provisioning or authorization.

It is the same argument we had at the BOF and at charter writing.

Paul
ps. and for reaching local resources, we do already have mDNS, which
does not require running a split DNS world view.

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 22 Oct 2021 13:16:07 +0200 (CEST)

> Il 19/10/2021 04:07 Paul Wouters <[email-masked]> ha scritto:
> 

I agree, it's the same argument again. The underlying question has never been solved: should the accessibility of a destination from a network be controlled by the network? I don't think we will ever reach consensus on this - this is a policy issue and is IMHO out of scope.

In this specific case, you are concerned about possible misuses of this specification to do things that the specification forbids (take over domains that exist in the global DNS hierarchy). These misuses can be detected if the domain deploys DNSSEC, which they should do in any case; if the network also manages to block any other resolver including encrypted ones, then even DNSSEC won't help, but then, you already are in a very restricted environment and your only option is really not to use that network if you don't trust it (or use a VPN).

But even if you don't think that the safeguards above are sufficient, altering query results for domains that exist in the global DNS is still something that will happen anyway, no matter what we specify. "My network my rules" is not going away and technical devices will be deployed to that effect. This can't be a reason not to specify how to do things that are uncontroversial and widely in use (make sure "local" domains still work in a remote resolver scenario in which parties are not adversarial). 

This is why I support adopting the document.

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

---

From: tirumal reddy <[email-masked]>
Date: Sat, 23 Oct 2021 17:16:13 +0530

Hi Paul,

Please see inline

On Tue, 19 Oct 2021 at 00:52, Paul Wouters <[email-masked]> wrote:

> But this is the problem I don’t understand. If my internal network is
> corp.example.com, I can’t have my pvd fqdn within corp.example.com
> because the internal zone is not in the public dns, and your draft says to
> find the pvd in public dns. So there is no straight mapping of domains and
> then we are back at the security issue of one domain (pvd) vouching for
> another domain with no verifiable authorization of such a domain.
>

RFC8801 addresses your comments in Section 7, it explains that the PvD FQDN
MUST be resolved using the DNS servers indicated by the associated PvD. It
means corp.example.com would need to be in the public DNS. In the public
DNS it will resolve to a different A record than in the private DNS.
RFC8801 also says that the HTTPS server is likely to be located within the
same administrative domain as the default router.

> If I am the owner of example.com and I want a split dns for
> corp.example.com, which DNS records do I need, what dnsZones and what pvd
> fqdn?  Note that corp.example.org does not exist in the public dns.
>

PVD FQDN can be example.com and it needs to be resolved by the
network-designated resolver (it is mandated by RFC8801).  dnsZones will
include the private domain "corp.example.com" and the network-designated
resolver will be used to resolve this private domain if and only if NSEC
response comes from the public resolver.

>
>
>
>
>
> If a network wants to block newyorktimes.com, it can simply block access
> to all well-known DoH/DoT servers and if the client has enabled a strict
> A user has only a choice if it is presented with the domain list. Will
> that be part of the protocol ? If not, how do you prevent abuse (eg Hilton
> wifi blocking Priceline) using this method. That is irrespective of wether
> other blocking methods exist.
>

If access to the public resolver is blocked, processing of dnsZones will be
stopped as the client has no way of validating if the networking is lying
or not.

> If a user connects and automatically processed dnsZones then I think it
> does. Perhaps I will understand if you show me the full process for
> corp.example.org.
>

Sure, we added a detailed example in Section 5
https://github.com/tireddy2/split-horizon-dns/blob/main/draft-reddy-add-enterprise-split-dns-07.txt
.

> Currently, the network cannot tell me to send queries for certain domains
> to special servers. This draft changes that and I still do not understand
> the security mechanism that defends against this feature being abused.
>

The network is conveying to use the network-designated resolver discovered
using RA to resolve certain domains. It is not a special resolver.  If an
endpoint does not have any pre-configured public resolver, it will anyway
use the network-designated resolver.

> It’s part of the IKEv2 split DNS RFC.

Yes but it is not solving the problem when the BYOD is connecting to the
Enterprise WiFi. I see IKEv2 split DNS RFC is relying on well-known domains
to identify if the VPN service provider is lying and it is not a full proof
security mechanism.

> That still requires worldwide offices to work together on LAN deployment
> parameters. That’s not easy or foolproof, and could possibly lead to DNS
> resolution failures.
>

Yes, with this I-D, breakage will occur if networks block DNS queries to
the Internet. If they permit it, those networks can work with this draft
and can roll out support for this I-D without breaking their existing DNS
deployments.

> ACME requests and CT requirements ?

It is possible to get PKIX certificates, see
https://blog.heckel.io/2018/08/05/issuing-lets-encrypt-certificates-for-65000-internal-servers/

> default (see https://wiki.mozilla.org/Trusted_Recursive_Resolver).  What
> is the need to perform validation for ".local" domains and how do you
> propose to perform validation for ".local" domains ?
>
>

They are not registered in SUDN (see
https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml
).

> I still don’t have an answer that allows me to follow the authorization
> and authentication steps of this protocol.
>
>
>
> We will update the draft to say the "additional precaution" is optional
> and even if the well-known domain check fails to identify the network is
> lying, the mechanism discussed in Section 4.1 is mandatory to identify if
> the network is lying.
>
>
>
> Once the core protocol is clear, we can revisit the security
> considerations section. But this document makes core changes to security
> models by carving into the public DNS, and it requires careful
> consideration and mitigation in the protocol that’s more than a security
> consideration section.
>

Sure, we will remove the optimization in the next revision to avoid
confusion.

-Tiru

---

From: Jim Reid <[email-masked]>
Date: Wed, 27 Oct 2021 15:27:07 +0100

> On 12 Oct 2021, at 16:56, Deen, Glenn <Glenn_Deen=[email-masked]> wrote:
> 
>  
> 	• Draft-reddy-add-enterprise-split-dns
> 	• Draft-boucadair-add-deployment-considerations https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/

I support WG adoption of both drafts.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Oct 2021 21:11:06 -0700

Hi Glenn,

Let me start by saying that I don't agree with a number
of your assertions here, in particular about the requirements
for adoption. While it's not *simply* a matter of numbers,
having a reasonable level of support is in fact necessary
for consensus.

However, before we debate those, let's start by getting to common
facts. I believe Tommy wrote you with concerns about both drafts, but
let's start with draft-boucadair-add-deployment-considerations.

I have provided you with a list of the people expressing each
position. Your message lists Jim Reid and Diego Lopez.  I am unable to
find a message indicating support for this draft from Diego though did
find one from Jim Reid. However, in that search I also find a message
somewhat opposing adoption from Martin Thomson (I belive he is opposed
so I'm sure I can arrange for a more direct message if you like).

So, can you please provide links to the messages from people who
are in support of this draft?

-Ekr

On Tue, Oct 12, 2021 at 8:57 AM Deen, Glenn <Glenn_Deen=
[email-masked]> wrote:

> Both drafts are material that has had good discussion both on list and
> during past ADD meetings so please consult the archive and meeting minutes,
> especially IETF110 and IETF111 if you need additional background.
>
>
>

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 29 Oct 2021 20:49:15 +1100

For clarity.

I said that the deployment considerations shouldn't be published.  Having read more feedback, I am now more of the opinion that it would also be a waste of time adopting it.

On Fri, Oct 29, 2021, at 15:11, Eric Rescorla wrote:
> On Tue, Oct 12, 2021 at 8:57 AM Deen, Glenn 
> <Glenn_Deen=[email-masked]> wrote:
>> Hi ADD,____
>> __ __
>> I wanted to bring to the ADD Group’s attention that 2 documents have entered into CALL for WG Adoption in the last couple of days:____
>> __ __
>> __ __
>>  1. Draft-reddy-add-enterprise-split-dns   https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/____
>> __ __
>> 
>>  1. Draft-boucadair-add-deployment-considerations https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/____
>> __ __
>> __ __
>> __ __
>> Both drafts are material that has had good discussion both on list and during past ADD meetings so please consult the archive and meeting minutes, especially IETF110 and IETF111 if you need additional background.____
>> __ __
>> Both are in a 2 week call for adoption, with the first ending on Oct 26,2021 and the second on Oct 27,2021.____
>> __ __
>> Please respond on list with comments on these calls.____
>> __ __
>> Regards____
>> Glenn____
>> -- 
>> Add mailing list
>> [email-masked]

---

From: "Diego R. Lopez" <[email-masked]>
Date: Fri, 29 Oct 2021 10:08:15 +0000

Hi,

Just for the sake of clarity… I replied to a message from Med, that I assumed was referring to both drafts, but I now notice it did only mention the one on split horizon. FWIW, my intent was to express support for both drafts, and I take the opportunity to explicitly do so, with my apologies for the confusion.

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

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

e-mail: [email-masked]<mailto:[email-masked]>
Mobile:  +34 682 051 091
----------------------------------

On 29/10/2021, 06:12, "Add on behalf of Eric Rescorla" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

Hi Glenn,

-Ekr

On Tue, Oct 12, 2021 at 8:57 AM Deen, Glenn <Glenn_Deen=[email-masked]<mailto:[email-masked]>> wrote:
Hi ADD,

2.      Draft-boucadair-add-deployment-considerations https://datatracker.ietf.org/doc/draft-boucadair-add-deployment-considerations/

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

________________________________

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: Geoff Huston <[email-masked]>
Date: Mon, 1 Nov 2021 06:17:17 +1100

Hi Eric,

So here we are in a call as to whether documents should be discussed by the WG and we are doing just that. Seems to me that the adoption question is already answered.

No, I do not believe that WG adoption means that the document describes a good idea nor one that is going to lead to some published document(s). It means that a bunch of folk want to talk about it and discuss their various interpretations of the concepts exposed in the document(s). It may lead somewhere. Or it may be a set of terrible ideas and lead nowhere. And that’s fine. WG Adoption is not an endorsement of the concepts, nor should it ever be.

I support DISCUSSING these draft. I don’t necessarily agree with the draft, nor can I (or anyone else for that matter) claim that the WG “supports” these drafts until the WG discusses them. I don’t support peremptorily stopping discussion of these drafts by not adopting these document. It appears that they are in scope for the WG’s area of study, and I that’s a reasonable position to support adoption by the WG group.

regards,

   Geoff

> On 29 Oct 2021, at 3:11 pm, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Glenn,
> 
> On Tue, Oct 12, 2021 at 8:57 AM Deen, Glenn <Glenn_Deen=[email-masked]> wrote:
> Hi ADD,
> 
>  
> 
> 	• Draft-reddy-add-enterprise-split-dns   https://datatracker.ietf.org/doc/draft-reddy-add-enterprise-split-dns/
>  
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 31 Oct 2021 12:52:24 -0700

Adoption does not mean that the document can be discussed. Documents can be
discussed by WGs without being adopted. Indeed, this often happens for
quite some time before WG adoption, especially in cases where there are
multiple candidate WG documents for the same use case.

WG adoption means (at minimum):
1. The WG is taking control of the document
2. The WG intends to work on the document
3. The WG will prioritize work on this document above non-adopted documents.

For the reasons I indicated in my objection, I do not believe that this in
fact is what we should do with the deployment considerations document (and
increasingly, with the other, though my objection was not to that).

-Ekr

On Sun, Oct 31, 2021 at 12:17 PM Geoff Huston <[email-masked]> wrote:

> Hi Eric,
>
> So here we are in a call as to whether documents should be discussed by
> the WG and we are doing just that. Seems to me that the adoption question
> is already answered.
>
> No, I do not believe that WG adoption means that the document describes a
> good idea nor one that is going to lead to some published document(s). It
> means that a bunch of folk want to talk about it and discuss their various
> interpretations of the concepts exposed in the document(s). It may lead
> somewhere. Or it may be a set of terrible ideas and lead nowhere. And
> that’s fine. WG Adoption is not an endorsement of the concepts, nor should
> it ever be.
>
> I support DISCUSSING these draft. I don’t necessarily agree with the
> draft, nor can I (or anyone else for that matter) claim that the WG
> “supports” these drafts until the WG discusses them. I don’t support
> peremptorily stopping discussion of these drafts by not adopting these
> document. It appears that they are in scope for the WG’s area of study, and
> I that’s a reasonable position to support adoption by the WG group.
>
> regards,
>
>    Geoff
>
>
>
>
>
> >       • Draft-boucadair-add-deployment-considerations

---

From: Michael Richardson <[email-masked]>
Date: Sun, 31 Oct 2021 15:58:02 -0400

> the WG and we are doing just that. Seems to me that the adoption
    > question is already answered.

    > No, I do not believe that WG adoption means that the document describes
    > a good idea nor one that is going to lead to some published
    > document(s). It means that a bunch of folk want to talk about it and
    > discuss their various interpretations of the concepts exposed in the
    > document(s). It may lead somewhere. Or it may be a set of terrible
    > ideas and lead nowhere. And that’s fine. WG Adoption is not an
    > endorsement of the concepts, nor should it ever be.

I strongly agree with Geoff.

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 31 Oct 2021 13:21:57 -0700

> On Oct 31, 2021, at 12:17 PM, Geoff Huston <[email-masked]> wrote:
> 
> Hi Eric,
> 

On the case of the split-DNS document, I think the main crux of the issue is how a network establishes ownership over a domain in a way that clients can trust, and should trust more than other alternatives. That might be something that’s in scope if we discuss it, but I’m seriously wondering if that is a bigger problem that needs a more general mechanism that just what’s used for bootstrapping an encrypted resolver (the topic of ADD). I think having these private-scoped PvDs is quite interesting, but given that a lot of work was done for PvDs elsewhere (like in intarea), it may be that this mechanism mainly belongs in another group or a new group entirely. That’s the kind of discussion that’s useful to have prior to adoption. 

Thanks,
Tommy

---

From: Paul Wouters <[email-masked]>
Date: Sun, 31 Oct 2021 17:19:05 -0400

On Oct 31, 2021, at 16:22, Tommy Pauly <tpauly=[email-masked]> wrote:
> 
> On the case of the split-DNS document, I think the main crux of the issue is how a network establishes ownership over a domain in a way that clients can trust, and should trust more than other alternatives.

And I still cannot figure out how this system is supposed to work. I read the document and it’s references. I asked questions and for some answers but I still don’t understand how it can work. While I am happy to discuss the idea of split dns authorization and authentication in the WG, I don’t think this document is ready for an adoption call.

> That might be something that’s in scope if we discuss it, but I’m seriously wondering if that is a bigger problem that needs a more general mechanism that just what’s used for bootstrapping an encrypted resolver (the topic of ADD). I think having these private-scoped PvDs is quite interesting, but given that a lot of work was done for PvDs elsewhere (like in intarea), it may be that this mechanism mainly belongs in another group or a new group entirely. That’s the kind of discussion that’s useful to have prior to adoption. 

I agree. This was always an issue of the ADD working group.

Paul