Re: [Add] draft-reddy-add-enterprise-split-dns, was Re: ADD Calls for WF Adoption

tirumal reddy <kondtir@gmail.com> Sat, 23 October 2021 11:46 UTC

Return-Path: <kondtir@gmail.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1A3A096D for <add@ietfa.amsl.com>; Sat, 23 Oct 2021 04:46:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A8nFB0yIzpTv for <add@ietfa.amsl.com>; Sat, 23 Oct 2021 04:46:29 -0700 (PDT)
Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7ECC3A0972 for <add@ietf.org>; Sat, 23 Oct 2021 04:46:28 -0700 (PDT)
Received: by mail-lj1-x22b.google.com with SMTP id q16so3550115ljg.3 for <add@ietf.org>; Sat, 23 Oct 2021 04:46:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRHCFdzj0VU0Lnado3bjPRQH+RKg805TTGE9smU9o0g=; b=ZcKSIJ1OsuCB8kdvlBDk2gnXmYl68X9uhDWLyYNFLpLDSKPoZaoVikZujm+9opoWzk LaQC0+BQgsKhhrhCoovgwwWnEDdgJFQI9/o3sr68iV7GQmCm7bdkltA/JVmLxi5Qh67H fT7BcmIV2QRxP3aUxJppMZx5CT3oinWab9o0fKQ0CSOtvoZ9+xCAFMRL/jrJM1iCPUMI NdEPT1NuLtyEQyz5nLla8LfCYrrsHkNHB0PL2TcCCtS6U4XFvAcOu7Eeu2H6Li/IG9M7 NGyr+ewwLe1MlxB7ekdLRMpx+aGAzDhEbNMT+A32OpgeS6x9PGJ8LjDtvbcjGZS4Wlt0 0Vlg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CRHCFdzj0VU0Lnado3bjPRQH+RKg805TTGE9smU9o0g=; b=WjX0Eieeb/KfhzFjFuxrGKocHeNC3chnd30hdjV++olGYOjknMLZz4QYNgjRNeEeNk xhjurLbb0x5RRI4tld0fj+Y72xYV+bqJN2XxP6dMNHciLL69lzjPCrFbCo13H8DL4Ngy wuy4GOM/0yMNdifLD9CPjFZq20/L16Umr9mgEDRBrAfNWR78DasozS6mZHEozQ3K6xEU wUddJXNxVBRjfyqhvtEZwwd5T+aEtW0g5KkPKbhupbos6hRwPKsWyF7+6iiCfjeaXNxu gqN0xrvbsjvyaALrTaKGK+4pJVxVlC1KJ+Q+j3T86TrKpojBOpNJeTSog0rbxySl8Ovc dN/A==
X-Gm-Message-State: AOAM5329mKWwvzCBDJAW+LFlJhMz/3Vy7lDUvxLued0drJMYBIm3c1Wa cKiWK+OBxTdcf8dRqOIDEq8f+t7OmZg0DNNXQjJRTNsIDmE=
X-Google-Smtp-Source: ABdhPJwYCimWfjrn7nVgbc3V/bVP4nR6hZGOfiAD+2TXTHLzUNrDBrGAv4UI0EQG5Ai7DbNx7TOsjQlS4fE/x04aSuE=
X-Received: by 2002:a2e:a584:: with SMTP id m4mr6080685ljp.489.1634989585041; Sat, 23 Oct 2021 04:46:25 -0700 (PDT)
MIME-Version: 1.0
References: <CAFpG3gezo6gU8Rv4kqOQhQ40FxLWGrvM45c9qCJUK_WZOwrxNw@mail.gmail.com> <4DA975D3-09EC-46FA-A4E6-EE47829EAD1B@nohats.ca>
In-Reply-To: <4DA975D3-09EC-46FA-A4E6-EE47829EAD1B@nohats.ca>
From: tirumal reddy <kondtir@gmail.com>
Date: Sat, 23 Oct 2021 17:16:13 +0530
Message-ID: <CAFpG3gcnCasO4fyBX79Zb2M+nzkO4RPen==0fJqT5_5UbeWK=A@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Paul Wouters <paul.wouters@aiven.io>, Paul Wouters <paul.wouters=40aiven.io@dmarc.ietf.org>, ADD Mailing list <add@ietf.org>, "Deen, Glenn" <Glenn_Deen=40comcast.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006d8ae705cf03ad52"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/fX2V4eO3Grp9JhGjMgnAV47Px-g>
Subject: Re: [Add] draft-reddy-add-enterprise-split-dns, was Re: ADD Calls for WF Adoption
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Oct 2021 11:46:35 -0000

Hi Paul,

Please see inline

On Tue, 19 Oct 2021 at 00:52, Paul Wouters <paul@nohats.ca> wrote:

> On Oct 18, 2021, at 02:42, tirumal reddy <kondtir@gmail.com> 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.
>
> We will remove the text from the Terminology section.
>
>
> Okay.
>
>
>  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.
>>
>
> 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.
>

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.



>
>
>>
>> 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" ?
>
>
> 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.
>

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
> 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.
>

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.


>
>
> 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.
>

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
.


>
>
>
>
>> >      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 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.
>

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.


>
>
>> > I see no capability in the
>> protocol for this, so using this protocol always causes a downgrade from
>> DNSSEC to non-DNSSEC.
>>
>
> 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.
>

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.


>
>  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.
>>
>
> 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.
>

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.


>

>
>
> 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 ?
>>
>
> 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 ?
>

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



>
>
>
>> 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.
>>
>
> 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.
>

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


>
>
>
>>
>> >           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.
>>
>> 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.
>>
>
> I still don’t have an answer that allows me to follow the authorization
> and authentication steps of this protocol.
>
>
>
>> >       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.
>> >
>> > 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.
>>
>
> 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.
>

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

-Tiru


>
> Paul
>