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