Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)
mohamed.boucadair@orange.com Thu, 21 July 2022 06:52 UTC
Return-Path: <mohamed.boucadair@orange.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 D4E33C06B994; Wed, 20 Jul 2022 23:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYLY1VzEpwMD; Wed, 20 Jul 2022 23:52:28 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8272FC157B5A; Wed, 20 Jul 2022 23:52:28 -0700 (PDT)
Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4LpNY541Lzz121d; Thu, 21 Jul 2022 08:52:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1658386345; bh=4od1IGUHZfmR9ep3ONDRMffK4D5ihuU+ieEm378CTc4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=WQungcW+vq7+XCb90acZ+4X05Ht7V0XFs55I4yR8IMysbXvn3MmvmDcsLl60ZrIXX rQsAlT9svq90L0IYJX9nMkRNFQXpEdxSpbgdKsV+GVC72fYiuTogXtgwSRZlF6JDYX IZH0p6p4h+HE5hZdY2S7qL93My37NKDc+XEkqy6+66ghks0GSz7Ig/37vjXbazK1V8 hV0riLwLzij5HDzRF95anpV9B3OEnU/ldSokRvwImB20QT1daOR2gDT7Os1ozVqdE7 ctW8ozBaGMlDn/cWlhoMAod+w8uC3uvyziRkNc7bqbjFjFxl3Ve/3HloWxb24ncbVZ 6tuNOy24CkL0A==
From: mohamed.boucadair@orange.com
To: Paul Wouters <paul@nohats.ca>, Dan Wing <danwing@gmail.com>
CC: Paul Wouters <paul.wouters@aiven.io>, The IESG <iesg@ietf.org>, "draft-ietf-add-dnr@ietf.org" <draft-ietf-add-dnr@ietf.org>, ADD Chairs <add-chairs@ietf.org>, ADD Mailing list <add@ietf.org>, "Andrew.Campling@419.consulting" <Andrew.Campling@419.Consulting>
Thread-Topic: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)
Thread-Index: AQHYnEyOU0OFdoNzmEeXf69jYaERha2IXefw
Content-Class:
Date: Thu, 21 Jul 2022 06:52:25 +0000
Message-ID: <22662_1658386345_62D8F7A9_22662_46_1_b8749b139bb74f9a9d76ee1839fdad66@orange.com>
References: <165774161599.52839.7342794318640205540@ietfa.amsl.com> <52F5AF14-52D4-434B-AB19-A0C5BE5D9B59@gmail.com> <34d46ff-7137-4195-bed9-21aa1082fff7@nohats.ca>
In-Reply-To: <34d46ff-7137-4195-bed9-21aa1082fff7@nohats.ca>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2022-07-21T06:30:33Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=28f5a817-0a13-4bd6-a6ab-c92839d46771; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0
x-originating-ip: [10.115.26.52]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/zRcvHWg5Vk8LkurJ_C5vLWkZjJY>
Subject: Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: (with DISCUSS)
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.39
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: Thu, 21 Jul 2022 06:52:32 -0000
Hi Paul, all, FWIW, the changes we made to address your review can be tracked at: https://tinyurl.com/latest-dnr-changes. The new version will be made public once the submission system reopens. I understand that you are interested in seeing added some text about CPEs, forwarders, ACME-signed certificates for systems without Internet connectivity, etc. These are good points but from a deployment standpoint and are out of the scope of the DNR spec. FYI, the draft used to include these matters but the WG asked us to remove those into a separate document: https://datatracker.ietf.org/doc/html/draft-boucadair-add-deployment-considerations. As authors, we think that the deployment draft is useful as it exemplifies how to glue various pieces. A call for adoption was issued for that document, but the conclusion was that ** the material in the draft goes beyond the ADD charter **. Hope this clarifies the area we are navigating in and the constraints we have as editors. Cheers, Med > -----Message d'origine----- > De : Paul Wouters <paul@nohats.ca> > Envoyé : mercredi 20 juillet 2022 17:23 > À : Dan Wing <danwing@gmail.com> > Cc : Paul Wouters <paul.wouters@aiven.io>; The IESG > <iesg@ietf.org>; draft-ietf-add-dnr@ietf.org; ADD Chairs <add- > chairs@ietf.org>; ADD Mailing list <add@ietf.org>; > Andrew.Campling@419.consulting > Objet : Re: [Add] Paul Wouters' Discuss on draft-ietf-add-dnr-11: > (with DISCUSS) > > On Tue, 19 Jul 2022, Dan Wing wrote: > > > overarching issue of "never use or trust the local DNS > resolvers" trumps > > the DNR /DDR protocols. For those who can dictate how > their users MUST > > use DNS (eg Enterprise usage, parental control, opt-in > security software), > > device provisioning/configuration options are available > that require no > > ADD protocols with the exception of draft-ietf-add-svcb- > dns. > > > > > > The above Discuss has since been moved to a Comment. I observe > that > > IETF's OHAI working group hides client IP addresses from servers > -- > > including DoH and CRL checking -- to improve client > privacy. Other > > mechanisms exist which help improve client privacy, such as > much-hated > > carrier-operated NAPT (CGN). With DNS, both caching and DNS > proxying > > (with recursive > > resolvers) help to hide the querying client's IP address from > DNS > > servers. The > > EDNS0 option to expose the first 24 bits of client's IPv4 > address to > > DNS servers encountered resistance around its standardization in > 2010 > > until its eventual publication as an informational document as > RFC7871. > > > > IETF has acknowledged in the past that client IP addresses are, > > themselves, something that is best hidden from public DNS > servers. > > The non-public DNS servers advertised through ADD protocols > attempts > > to preserve that characteristic to avoid clients communicating > directly with public servers. > > It hides it from the central DNS providers by exposing them to all > the local DNS providers. When walking around with my phone, I'd > argue the latter is worse. > > It is unfortunate that the ADD charter left client behaviour out > of the charter, so that now we are specifying discovery options > for the server, and leave the client behaviour completely > unspecified. It is a bit odd, like we wouldn't specify NFS server > protocols without specifying NFS client protools, but that is > where we are unfortunately. This is why I moved it from discuss to > comment. > > > ### > > > > Encrypted DNS servers need a public FQDN because otherwise > you cannot get > > a certificate for all connecting clients that are not > provisioned with a > > private/enterprise CA. How do home users run their own > without having a > > public domain? And how do I authenticate the encrypted DNS > on 10.1.1.1 > > that has no FQDN? (and really, has no verifiable identity > at > > all) > > > > > > Tiru explained how one of his previous employers has built such > a > > system: basically the in-home CPE does its public/private key > > generation, builds a certificate signing request, and sends the > CSR to > > a service that will perform the ACME proof-of-control to get an > ACME-signed certificate. > > > > The CPE never needs to respond to ACME requests on the Internet > and > > the CPE never needs a publicly-routable IP address. The CPE can > be > > behind multiple layers of NAT. > > > > The CPE's name can be named after its BSSID (MAC) address, which > I > > have noticed in my own neighborhood (linksys-a3d65b) so could > have > > SN=a3d65b.comcast.net) or allow the home user to provide a > vanity name > > SN=frodo.comcast.net. > > > > It seems we should add a discussion of such a mechanism to the > document? > > This is great information! It would be great to add this to the > document with a small discussion on the limits of CPE and this as > one possible solution. (if there is IPR on this, please do file an > IPR claim to the IETF) > > > ### > > > > The DNS client verifies the connection based on PKIX > > validation > > > > No CRLs, OneCRL updates, no OCSP, no Certificate > Transparency is available > > without functional DNS. So full PKIX validation as > specified here is not > > available. > > > > > > I added the following Aside in a new pull request, > > > > | PKIX validation often requires downloading data from > external > > | servers (e.g., certificate revocation lists, > certificate > > | transparency) which requires using DNS. Applications > SHOULD > > | NOT be allowed to use an encrypted DNS server until > those > > PKIX > > | validations have completed for that encrypted DNS > server. > > This addresses a lot of my concerns, thank you! > > > > > ### > > > > Spoofing attacks are mentioned in the document. Obtain > _any_ certificate from Let's > > Encrypt via ACME, eg using "something.example.com", then > spoof authentication-domain-name > > on the wifi. While this attack might be blocked by the AP > not allowing wifi clients to > > send packets to each other, this is not true for all > networks, and especially not for > > home networks where the goal is for local clients to be > able to connect to each other. > > Is there a better way to lock the authentication-domain- > name? One possible method might > > be to bind it to the ESSID. eg if the ESSID is > wifi.nohats.ca. one could only allow > > authentication-domain-name to be a name within nohats.ca. > Some method of reducing the > > scope of this attack is needed I believe. > > > > > > This is an appealing idea and could help authenticate other > systems on > > the local network -- the peer for the peer-to-peer communication > you > > mention is desirable in home networks, but also the printer, > NAS, and > > smart TV. Perhaps the answer is 802.1x or the answer is an > > IETF-designed captive portal mechanism which proves the WiFi > > connection is with the intended network (rather than a rogue > network). > > It's difficult/impossible to get all the servers on the network, > especially a home network, to follow a friendly naming scheme and > to obtain ACME certificates (printers, NAS, smart TV). > > > > I could imagine a quality implementation could map BSSID to a > TLS SAN > > for the network-advertised DNS server. I would enjoy connecting > to my > > home network and its advertised DNS and a (D)TLS handshake > performed > > to verify it's really my DNS server. The SAN could be learned > using > > TOFU and checked thereafter with a warning if the SAN changed. > > Obviously this breaks if the WiFi name is 'linksys' or some > other > > common name, but works great for more unique ESSIDs. This could > even > > be used to distribute SEND keys to secure DHCP, but now I'm > dreaming > > -- this all should have been done by IEEE, of course, but it may > > finally be time for IETF to improve the deficiencies of WiFi > while, at > > the same time, also improving wired Ethernet (which suffers the > same problem -- I have two jacks that were mislabeled in my home > office and the one on the DMZ network but wasn't immediately > obvious for an afternoon...). > > > > For the DNR internet draft, however, we are stuck with what IEEE > > provided the industry with WiFi. If the security model of WiFi > is > > insufficient, IETF could take a longer term approach to improve > it > > (which I would personally welcome and participate in), but for > the DNR I-D we don't want the perfect to be the enemy of good > enough. > > Noted :) Yes, lots of ways to improve outside of ADD. > > > ### > > > > By default, Encrypted DNS connections received from > outside the local > > network MUST be discarded by the encrypted DNS forwarder > in a CPE. > > > > What is an "encrypted DNS forwarder in a CPE"? This is not > defined in the > > document and I am confused. I assume the CPE announces > some encrypted DNS > > server as either itself or to some external IP at the ISP > network? > > > > > > Today, most CPE do not respond to DNS over UDP/53 queries on > their > > public (WAN) interface. This statement in the Internet Draft is > > pointing out that CPE implementing DoH/DoT/DoQ ("encrypted DNS > > forwarder") should continue with that practice of not responding > to queries on their public (WAN) interface. > > > > The -12 version of the document eliminated the "Encrypted DNS > forwarder" term. > > Thanks, I'll have a read once it appears. > > > If itself, how can it get a real FQDN the client can > verify with PKIX > > using CAB/Forum ? If to an external IP, isn't it just > acting as a NAT/router > > forwarding packets and then what does it mean to be an > "encrypted DNS forwarder" ? > > > > Tiru described a mechanism a few days ago, and I summarized that > > mechanism above in this email (generate CSR and perform ACME > > proof-of-control on an Internet-connected server). > > Indeed. Thanks. > > > This raises the big question of why you think that > strategy is a "fallback > > strategy" and not the default behaviour of the client. > Wouldn't it be more > > secure if there is no DHCP/RA drop attacks possible? See > my introduction text. > > > > We could alternatively have a fallback strategy of un-encrypted > DNS over 53 -- which is what users experience today. > > This may well be better than using a public resolver, because > there > > may not have been a public resolver configured, it could be > blocked, > > and the public resolver won't know of split horizon DNS names -- > which > > might well be available from the network-provided DNS (we don't > know > > via the DNR mechanism or via DHCP or BOOTP if split horizon DNS > is > > being used on this network). It creates the worst sort of bid- > down > > attack, however: the possibility of doing encrypted transport > has been abandoned and the client is using plaintext to the > network's DNS. I suppose this could be handled in the UI as > removing the lock icon for that network connection -- but that is > an implementation-specific choice and beyond purview of IETF, of > course. > > Yes I think this mostly depends on the UI. If a user is not told > their DNS is "encrypted", then doing encryption to an untrusted > party is better than unencrypted. But as soon as the user gets > some kind of notification on this, things change. > > > Mohamed answered this well yesterday and mentioned the text is > > reverting to the version we had in -10 which is clearer, > > https://raw.githubusercontent.com/boucadair/draft-btw-add-home- > network > > /master/draft-ietf-add-dnr.txt, > > and now reads in the unpublished -12, > > > 3.4. Multihoming Considerations > > > > Devices may be connected to multiple networks; each providing > their > > own DNS configuration using the discovery mechanisms > specified in > > this document. Nevertheless, it is out of the scope of this > > specification to discuss DNS selection of multi-interface > devices. > > The reader may refer to [RFC6731] for a discussion of issues > and an > > example of DNS resolver selection for multi-interfaced > devices. > > Also, the reader may refer to > > [I-D.ietf-add-split-horizon-authority] > > for a discussion on how DNR and Provisioning Domains (PvDs) > Key > > "dnsZones" (Section 4.3 of [RFC8801]) can be used in Split > DNS > > environments (Section 6 of [RFC8499]). > > Thanks, this is a good improvement and resolves my issue on that. > > Paul _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- [Add] Paul Wouters' Discuss on draft-ietf-add-dnr… Paul Wouters via Datatracker
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… tirumal reddy
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Eliot Lear
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Paul Wouters
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Paul Wouters
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… mohamed.boucadair
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… tirumal reddy
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… mohamed.boucadair
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… mohamed.boucadair
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Dan Wing
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Paul Wouters
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Ben Schwartz
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… Michael Richardson
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… mohamed.boucadair
- Re: [Add] Paul Wouters' Discuss on draft-ietf-add… tirumal reddy