Re: [homenet] [EXT] securing zone transfer
"Ray Hunter (v6ops)" <v6ops@globis.net> Fri, 28 June 2019 12:35 UTC
Return-Path: <v6ops@globis.net>
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 814121200FB for <homenet@ietfa.amsl.com>; Fri, 28 Jun 2019 05:35:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 U6Mk5lkBXVvB for <homenet@ietfa.amsl.com>; Fri, 28 Jun 2019 05:35:35 -0700 (PDT)
Received: from globis01.globis.net (92-111-140-212.static.v4.ziggozakelijk.nl [92.111.140.212]) by ietfa.amsl.com (Postfix) with ESMTP id BFDA0120058 for <homenet@ietf.org>; Fri, 28 Jun 2019 05:35:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 7ACFD401FB; Fri, 28 Jun 2019 14:35:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at globis01.globis.net
Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkGfzC1q83Ye; Fri, 28 Jun 2019 14:35:30 +0200 (CEST)
Received: from MacBook-Pro-3.local (h9041.upc-h.chello.nl [62.194.9.41]) (Authenticated sender: v6ops@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 2E8D64012D; Fri, 28 Jun 2019 14:35:30 +0200 (CEST)
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: Jacques Latour <Jacques.Latour@cira.ca>, homenet <homenet@ietf.org>
References: <CADZyTkkgd8f49V+yoZvPZXx3b-_YRzpgUY1-obroq9QMLnFWNw@mail.gmail.com> <cca26a8147924f1ab0d9447e3f083e0c@cira.ca> <CADZyTkmm_kW_EV70A2w3_bF2MWskqU2=QOxTf8rAgHPqD0BzRQ@mail.gmail.com>
From: "Ray Hunter (v6ops)" <v6ops@globis.net>
Message-ID: <3df461ee-e096-4f60-ccbc-b1abab71a61e@globis.net>
Date: Fri, 28 Jun 2019 14:35:28 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <CADZyTkmm_kW_EV70A2w3_bF2MWskqU2=QOxTf8rAgHPqD0BzRQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------192D243162B45DDBE3D16FAF"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/homenet/4n_aFJXzyoLLBSkWD-WM1r1VQ4Q>
Subject: Re: [homenet] [EXT] 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: Fri, 28 Jun 2019 12:35:39 -0000
Hi, Ted made a valid point about "running code" in this thread. So I've been experimenting with various configurations. My conclusions: 1) We definitely need to properly secure communication between the HNA and the DM for control traffic. This needs to be an explicit part of the draft. 2) Authentication based on the physical connection, plus source IP address, plus correlation of the source address against the contents of the RR *might* be sufficient for transactions between the HNA and the DM for reverse zones - all communication is guaranteed to be contained within a single AS. Current best practice of using IP ACL's + BCP 38 for filtering communication could work in this case. The DM would then check whether the contents of the PTR updates arrived from a source address associated with the HNA. We'd need to add some text saying the HNA should select source addresses for reverse zone updates appropriately (to make sure the updates came from an address issued via IA-PD from this ISP). 3) for communication between the HNA and a DM for forward zones, we definitely need to specify something stronger, because the DM potentially has to serve HNA's scattered over the entire Internet. 4) TSIG isn't going to scale operationally IMHO. Too many keys to manage. Keys have to be stored on line within the DM. Losing keys means compromising the whole service, and it is difficult to recover from. 5) SIG(0) has similar problems. Bootstrapping the trust might mean the expiration time would have to be so large that replay attacks will come into play. And recovery is difficult. 6) DNS over an existing standard FOO secure transport looks promising. The amount of traffic arriving at a DM should not be so large or time critical as the traffic to the resolvers, and capacity can be scaled by increasing the numbers of DM's. There is also existing front-end hardware acceleration available. So the secure transport could theoretically be terminated on an dedicated acceleration box, and the DM only then needs to speak native DNS. 7) DNS over TLS can almost certainly be made to work without any new standards, but it will require extensive coding as support seems pretty limited off the shelf. It also has the added benefit that client authentication can be built into the transport. So I've been playing around with the DM being authenticated by public certificates to the HNA (HNA would incorporate root certificates burned in at the factory), and the HNA being authenticated to the DM by a client-specific certificate that is signed using a self-signed intermediate CA certificate from the DM. The DM then trusts the certificates it has issued to the client HNA's simply by installing the root CA cert on the DM: there's no client specific configuration required. Since the HNA anyway has to be configured to use the DM, and some trust has to be established, I don't see this as an onerous burden in the sign up process. 8) DNS over HTTPS doesn't bring us anything extra in this case IMHO. It actually presents additional challenges with coding alternate transports and parsing (POST or GET HTTP1.1 HTTP2) etc. Others may disagree, so the draft could use a "recommend DNS over TLS" 9) IMHO we should also standardize the trust-booting process into a JSON file, that can either be fetched via HTTPS or pasted into the HNA. This for the same reasoning for inter-operability that DNS standardized the file representation of the zone file in RFC1035 Section 5. For a start, I came up with the following, although I'm sure we can improve as we get more experience in what parameters are needed for each implementation. I came up with 4 parameters: dm_axfr fqdn of the DM for axfr (so the HNA can apply IP filters on inbound requests) dm_ctrl fqdn of the DM for ctrl (so the HNA can send updates to the DM control channel e.g. if the HNA renumbers it would send an NS record and AAAA record update) zone the zone that is being delegated hna_certificate client certificate encoded as a single line with literal '\n' replacing cr and lf characters (common practice in existing equipment when pasting certificates) This would also work for a reverse zone, although obviously it's a different DM etc. Sample: {"dm_axfr":"dm.homenetdns.com","dm_ctrl":"dm.homenetdns.com","zone":"sub.homenetdns.com","hna_certificate":"-----BEGIN CERTIFICATE-----\nMIIDSzCCAjMCFGy+Htuv9ErWhDkwvFU8mzocStmTMA0GCSqGSIb3DQEBCwUAMIGm\nMQswCQYDVQQGEwJOTDEWMBQGA1UECBMNTm9vcmQgQnJhYmFudDESMBAGA1UEBxMJ\nRWluZGhvdmVuMRMwEQYDVQQKEwpIb21lbmV0IFdHMRkwFwYDVQQLExBIb21lbmV0\nIEhOQSBEZW1vMRowGAYDVQQDExFkbS5ob21lbmV0ZG5zLmNvbTEfMB0GCSqGSIb3\nDQEJARYQdHJhc2hAZ2xvYmlzLm5ldDAeFw0xOTA2MjYwNzMyNTVaFw0yNDA2MjQw\nNzMyNTVaMB0xGzAZBgNVBAMTEnN1Yi5ob21lbmV0ZG5zLmNvbTCCASIwDQYJKoZI\nhvcNAQEBBQADggEPADCCAQoCggEBAMRQaLn7+WLhm80//Wl3gKqcDwEJrJfNM+gm\n+fpHdR2Ec15DxPoaL2wBP2bnvVu5mJGO8EC03fD9ZvFAJ46kD+K79JBMdpV4r+fO\ny/PeajXIV3pwW7mPxNyfI2N2xCwtBIps9neTZhQVTivpgvLeCyhiyoMeELca6BVg\nTB6B7R/IDlAbwEPuVesw5xzErulrbzvl/K2diTJyAega+c8uSQMLDWN72u4F98s+\nfePINqnkKJ3a9FNPVA7QBUmLBWIEVdnKuat7oAR5iveOqj9KIjBzMOsw4jCmt25F\nXRHtO0LSUE0SVtg49nuCClyBxAgdbcpuDnJXieC46jXy7OS0v6UCAwEAATANBgkq\nhkiG9w0BAQsFAAOCAQEAGm7WhvgN5QEwL5+nqx/hV05yNPAGS8be9ZHQwv+33fIU\n4BdBrQatFdV+IIUByOYpkJ1j9oxzXxm2f8QpZhZyJCPvVeJCmH3wOn2RVwFQHxix\n0VfQWVWSkW5N+o5itue3e6Toc0TPkHCEq0VfLJCbfJpZJ6wkwc/PYA/SK1ThAJY0\nlkFN9xtPwOm6Jm8L8jFe3FQMDT0oDsJOmWkud4ziRx3g10P5JZ0toShK6EdCSU1W\nCGiYCI9eaRzXJfVOH/jnjDJneAfp3ad0MKTcTFMplpjibkahmCnW9XcIentRP7mu\n0zC9KEHHRDJM8HiivyB0RaI9vmKc08MBThU0OBvJgQ==\n-----END CERTIFICATE-----\n"} Thoughts? Daniel Migault wrote on 12/06/2019 04:20: > Hi Jacques, > > I agree the HNA cannot generate the full zone out of the box and needs > some information such as the NS. It also needs some information to > configure the primary / secondary relation such as the the IP of what > we now call the Distribution Master. DNS update on a specific zone > seems tempting especially as it is available code for it. Though I > might be biased, but i am not sure we need TSIG. I need more thoughts. > > Yours, > Daniel > > On Tue, Jun 11, 2019 at 3:00 PM Jacques Latour <Jacques.Latour@cira.ca > <mailto:Jacques.Latour@cira.ca>> wrote: > > Daniel, > > In trying to setup our secure home gateway project to have the > external zone & primary DNS server setup and managed on the > gateway itself and to XFR back to secondary name servers somewhere > turned out not be functional or practical, first, the gateway does > not know for sure which external NS are use by the secondary DNS > service, second, the IPs of the WAN port might not be the internet > facing IPs and this could break inbound connectivity. We’re > looking at using dynamic DNS updates for things that need internet > connectivity, and have the primary DNS server on the main land. > TSIG & DNS over TLS look like a good option to look at. > > Jacques > > *From:*homenet <homenet-bounces@ietf.org > <mailto:homenet-bounces@ietf.org>> *On Behalf Of *Daniel Migault > *Sent:* June 7, 2019 4:03 PM > *To:* homenet <homenet@ietf.org <mailto:homenet@ietf.org>> > *Subject:* [EXT] [homenet] securing zone transfer > > Hi, > > The front end naming architecture uses a primary and a secondary > dns server to synchronize a zone. The expected exchanges are (SOA, > NOTIFY, IXFR, AXFR. We would like to get feed backs from the > working group on what are the most appropriated way to secure this > channel. > > Options we have considered are TSIG, IPsec, TLS, DTLS. TSIG does > not provide confidentiality, and we would rather go for user space > security. Are there any recommendation for using TLS or DTLS in > that case ? > > Any thoughts would be helpful. > > Yours, > > Daniel > > _______________________________________________ > homenet mailing list > homenet@ietf.org <mailto:homenet@ietf.org> > https://www.ietf.org/mailman/listinfo/homenet > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- regards, RayH <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
- [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)