Re: [homenet] securing zone transfer
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 12 June 2019 01:26 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7879112006E for <homenet@ietfa.amsl.com>; Tue, 11 Jun 2019 18:26:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 xrO9SYohI3fJ for <homenet@ietfa.amsl.com>; Tue, 11 Jun 2019 18:26:35 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E583812002F for <homenet@ietf.org>; Tue, 11 Jun 2019 18:26:34 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 12D0738183; Tue, 11 Jun 2019 21:25:09 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id C2B42F29; Tue, 11 Jun 2019 21:26:31 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C02EDC07; Tue, 11 Jun 2019 21:26:31 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Juliusz Chroboczek <jch@irif.fr>, homenet <homenet@ietf.org>
In-Reply-To: <87ftofwqut.wl-jch@irif.fr>
References: <CADZyTkkgd8f49V+yoZvPZXx3b-_YRzpgUY1-obroq9QMLnFWNw@mail.gmail.com> <878su8fj24.wl-jch@irif.fr> <2348.1560261275@localhost> <87ftofwqut.wl-jch@irif.fr>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Tue, 11 Jun 2019 21:26:31 -0400
Message-ID: <27503.1560302791@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/swHSu1HZEVDDkcMEkFjf_opevfg>
Subject: Re: [homenet] securing zone transfer
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2019 01:26:37 -0000
Juliusz Chroboczek <jch@irif.fr> wrote: > Thank you for your detailed reply. I'm glad we're finally having > a discussion about my objections to Daniel's proposal. >> We strongly believe that the HNA needs to know the list of names in >> order to be able to answer for those names when there is unstable (or >> no) Internet connectivity. >> Otherwise, applications and people have to know two different names for the >> service. (A public one for when away, and the .local one) > That's a good point. While I happen to believe that it's reasonable to > have a service known as "boombox.local" from home, and > "boombox.jch.example.org" from the Internet, this might be inconvenient > for e.g. smartphone users. Actually, it's fatal, because you can't get a certificate for "boombox.local" so you can't secure it that way. So you always have to use the FQDN. >> o the credentials for the dynamic DNS server need to be securely >> transferred to the hosts that wish to use it. This is not a >> problem for a technical user to do with one or two hosts, but it >> does not scale to multiple hosts and becomes a problem for non- >> technical users. > I think that's our main disagreement. > For some reason, you guys seem to be assuming that the average user will > want to publish hundreds of names in the global DNS. Hundreds? How about two. My son wants to publish his desktop's name so that his friend can reach his system directly for minecraft. I want the same. Yes, it's native IPv6 the whole way, but they don't know that, and they don't have to know that. > However, none of the end-user services that I know use incoming > connections require a name in the global DNS to function (WebRTC, Skype, > online games, BitTorrent, remote desktops, BTSync/Resilio, syncthing). All of these are applications which either presently use cloud relays due to NAT, or exchange IP addresses within the protocol. All of these applications are built during the IPv4 mindset of scarcity. > Thus, my assumption is that the typical user will want to publish exactly > 0 public names, and that only the extreme geek will publish up to 3 or 4 > (music server, NAS, game server, web server with family photographs). > Richard, Daniel -- please be so kind as to explain why you think my > assumption is wrong. How many names do you envision wanting to publish in > the public DNS, and for what purpose? I think that you are living in the late 1990s IPv4 scarcity world. The gigabit connected IPv6 home doesn't have to be like that. I know at least twenty minor geeks who have music servers, NAS, game server boxes and that family web server. Yet, have no clue what an IP address is. Many of them have griped to me that there should be a way for them to easily give their stuff names that they can access. We've spoken at times of building more mesh networks here, but what's the point if you can't give things good names? Anyway, you don't have to publish any names if you don't want to. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [homenet] securing zone transfer Daniel Migault
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Ray Bellis
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Ted Lemon
- Re: [homenet] securing zone transfer Ray Hunter (v6ops)
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Ted Lemon
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Mark Andrews
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] [EXT] securing zone transfer Jacques Latour
- Re: [homenet] [EXT] securing zone transfer Ted Lemon
- Re: [homenet] [EXT] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] [EXT] securing zone transfer Ted Lemon
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] [EXT] securing zone transfer Daniel Migault
- Re: [homenet] number of devices in homenet Daniel Migault
- Re: [homenet] [EXT] securing zone transfer Ray Hunter (v6ops)
- Re: [homenet] securing zone transfer Ray Hunter (v6ops)
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Ted Lemon
- Re: [homenet] webauthn for routers (was: securing… MIchael Thomas
- Re: [homenet] webauthn for routers (was: securing… Michael Richardson
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Michael Richardson
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] securing zone transfer Michael Richardson
- Re: [homenet] securing zone transfer Ray Hunter (v6ops)
- Re: [homenet] webauthn for routers Michael Richardson
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] securing zone transfer Juliusz Chroboczek
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] webauthn for routers Ted Lemon
- Re: [homenet] webauthn for routers Michael Thomas
- Re: [homenet] [EXT] securing zone transfer Ray Hunter (v6ops)