Re: [dns-privacy] [Step 2] More discussion needed: state your opinion
Paul Wouters <paul@nohats.ca> Tue, 13 December 2016 16:26 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D38D0129BB5 for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 08:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 PL85PrshzPay for <dns-privacy@ietfa.amsl.com>; Tue, 13 Dec 2016 08:26:44 -0800 (PST)
Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA44129BB1 for <dns-privacy@ietf.org>; Tue, 13 Dec 2016 08:25:26 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3tdQ5q3fNSz378; Tue, 13 Dec 2016 17:24:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1481646287; bh=eKQLHB20cLDV0tRo/tcAirX5G/c+djlTQSqoytfSSHU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=krq5gjbOyoC5zhGv13dNJhKMQnRvBCcdmXRwBuZtflUqVuY+WH8036ME4TAvfGxlq JFFYhdHMCSecy20wAqzd1tz6AYIKnuKzSPvnaQQ7tIORtAXoB1UCerCgaTQsrjdzLX pj2JAEuaUwnCQQnfex/eAxFOodJcK5Zg7VXB/wDY=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id fVKvNO09RLyM; Tue, 13 Dec 2016 17:24:45 +0100 (CET)
Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 13 Dec 2016 17:24:45 +0100 (CET)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 47D59506F86; Tue, 13 Dec 2016 11:24:29 -0500 (EST)
DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 47D59506F86
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3451241CCC8E; Tue, 13 Dec 2016 11:24:29 -0500 (EST)
Date: Tue, 13 Dec 2016 11:24:29 -0500
From: Paul Wouters <paul@nohats.ca>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>
In-Reply-To: <20161213154133.prn6h7rdwk7md5aj@nic.fr>
Message-ID: <alpine.LRH.2.20.1612131054220.13896@bofh.nohats.ca>
References: <20161213105936.opaqw6hwwkx3txk2@nic.fr> <20161213154625.6b314fe6@pallas.home.time-travellers.org> <20161213154133.prn6h7rdwk7md5aj@nic.fr>
User-Agent: Alpine 2.20 (LRH 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/9mimePUJuncd0J_djzU1MhytQCw>
Cc: Shane Kerr <shane@time-travellers.org>, dns-privacy@ietf.org
Subject: Re: [dns-privacy] [Step 2] More discussion needed: state your opinion
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Dec 2016 16:26:47 -0000
On Tue, 13 Dec 2016, Stephane Bortzmeyer wrote: >> IIRC the idea of using IPsec was also discussed somewhere. IIRC, >> IPsec may have problems traversing NAT. It is also usually >> implemented by the kernel, which may cause deployment issues. I >> *want* IPsec to be an option here, but realistically I don't think >> it is. > > Eric Rescorla talked about it at the London BoF > <https://www.ietf.org/proceedings/89/slides/slides-89-dnse-5.pdf> "IPsec probably isn't going to work here" is a rather week conclusion. It seems mostly based on "I think people still firewall that stuff". Regardless of that, IKE over TCP is a draft that's currently going to go into WGLC any time now. And it can be encapsulated in pseudo or real TLS to break through misconfigured (or administratively blocking) networks. Which gives TLS and IKE/IPsec the same penetration capabilities. Also, if/when TLS would be used for encrypted DNS, malicious code will appear to use that as an exfiltration side-channel, so any middleware inspector device will go and MITM those connections anyway or simply block them. So I doubt this while "TLS will always get out the network for free" will be true in the long term. People might remember I did an IKE/IPsec presentation on that it can be used to protect DNS traffic when all this talk about using TLS or custom DNS encryption RRTYPE's came up, and when people talked about dnscrypt, which is just a generic VPN with a policy to only allow DNS. Which is why I wanted to remind people that we have existing technology in IETF that would work fine as a solution without re-inventing the wheel: https://www.ietf.org/proceedings/93/slides/slides-93-dprive-4.pdf It surely can work fine. IKEv2 allows IPsec clients to remain anonymous while authenticating the server, basically giving IKE a "TLS-like" security with anonymity. You can find an example using LetsEncrypt for IKE/IPsec at: http://events.linuxfoundation.org/sites/events/files/slides/LinuxSecuritySummit-2016-OE-16x9.pdf The only real differene between using IKE/IPsec and a "bolt on" crypto on the DNS packets is the generic difference between TLS and a (IP base) VPN. A VPN protects host-to-host traffic, and TLS protects a single stream. That has both advantages and disadvantages. And note TLS can be used both as a single stream of IP based VPN deployment: Pro VPN: - With IKE/IPsec (or generic VPN), multiple DNS (UDP and/or TCP) connections do not need to use their own separate crypto handshakes - Encryption can be "long lived" (eg hours) so no need crypto negotiation needed when you don't send queries for 5 minutes and all your TCP/UDP sessions were terminated by the DNS server. - IPsec/IKE or TLS can run on seperate hardware from the DNS server. - No modifications needed for DNS software - re-usable technology. Conn VPN: - With IKE/IPsec (or generic VPN) it becomes harder for the DNS authoritative server to know if a connection is unencrypted or encrypted. While that might not matter for the privacy element, as we will assume the DNS server will respond to all DNS clients regardless of its privacy level, it might make a difference for DNS-COOKIEs and other anti-amplification counter meassures that the server might want to do. - offloading crypto to seperate hardware introduces an unencrypted DNS stream between hardware and DNS servers. >> AIUI the draft, if we want to use DNS the problem is that we want to >> know how to encrypt a session to a name server, but we can't look up >> anything about the name server in the DNS because we don't yet know >> how to encrypt a session to the name server. > > I disagree. We can look up without keys. It just has to be without > privacy. Even better, since you are going to setup a secure connection to that name server anyway, there is no privacy lost by querying for its public key in DNS out in the open. Anyway, just some more data points of IKE/IPsec vs TLS. It's like margarine versus butter. I can't believe that's not butter versus trans fats will actually kill you of faster. Paul
- [dns-privacy] [Step 2] More discussion needed: st… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Wouters
- Re: [dns-privacy] [Step 2] More discussion needed… John Heidemann
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Wouters
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Hoffman
- Re: [dns-privacy] [Step 2] More discussion needed… Christian Huitema
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Hoffman
- Re: [dns-privacy] [Step 2] More discussion needed… Ilari Liusvaara
- Re: [dns-privacy] [Step 2] More discussion needed… Stephen Farrell
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Hoffman
- Re: [dns-privacy] [Step 2] More discussion needed… Paul Wouters
- Re: [dns-privacy] [Step 2] More discussion needed… John Heidemann
- Re: [dns-privacy] [Step 2] More discussion needed… Shane Kerr
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… Tirumaleswar Reddy (tireddy)
- Re: [dns-privacy] [Step 2] More discussion needed… Stephane Bortzmeyer
- Re: [dns-privacy] [Step 2] More discussion needed… John Heidemann
- Re: [dns-privacy] [Step 2] More discussion needed… Christian Huitema