Re: [DNSOP] An approach to DNS privacy
Florian Weimer <fw@deneb.enyo.de> Sun, 16 March 2014 15:04 UTC
Return-Path: <fw@deneb.enyo.de>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA5B1A0211 for <dnsop@ietfa.amsl.com>; Sun, 16 Mar 2014 08:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham
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 hiNaBFYM72Tb for <dnsop@ietfa.amsl.com>; Sun, 16 Mar 2014 08:04:17 -0700 (PDT)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 753A41A01D2 for <dnsop@ietf.org>; Sun, 16 Mar 2014 08:04:17 -0700 (PDT)
Received: from [172.17.135.4] (helo=deneb.enyo.de) by ka.mail.enyo.de with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) id 1WPCbh-0003N2-5U; Sun, 16 Mar 2014 16:04:09 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1WPCbh-0005PO-19; Sun, 16 Mar 2014 16:04:09 +0100
From: Florian Weimer <fw@deneb.enyo.de>
To: Phillip Hallam-Baker <hallam@gmail.com>
References: <CAMm+LwgZOPvGX_mzqmpt1zDj3cZdF0y2du=Di5q8Vfo4aYjNYw@mail.gmail.com> <87lhwj8y4d.fsf@mid.deneb.enyo.de> <CAMm+LwhH0Zq-Adok8YxDkHAUA+ga7eTLnyXAGxee=h8RivSm0g@mail.gmail.com> <87r46b78iw.fsf@mid.deneb.enyo.de> <CAMm+Lwid7ciEXXNEbXjXatsfYa1iSrpiN8vAT-_QifSp5z9uVg@mail.gmail.com>
Date: Sun, 16 Mar 2014 16:04:09 +0100
In-Reply-To: <CAMm+Lwid7ciEXXNEbXjXatsfYa1iSrpiN8vAT-_QifSp5z9uVg@mail.gmail.com> (Phillip Hallam-Baker's message of "Sun, 9 Mar 2014 10:54:34 -0400")
Message-ID: <8738iiw5g6.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/DsUqtA5whmN91RBm1AvZEfzIgRY
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] An approach to DNS privacy
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 16 Mar 2014 15:04:19 -0000
* Phillip Hallam-Baker: >> If your ordinary resolver operator is a "carrier" is somewhat >> questionable, but resolver operators generally comply with requests >> for cleartext copies of traffic transitioning through their networks. >> >> I have no doubts that these operators will ask implementors to add the >> necessary features to keep these capabilities--or they will just turn >> on indiscriminate query logging. > We are not a carrier or an obligated party. We aren't, but the people who run our protocols and code mostly are. If they aren't, they comply with most requests directed at them just to avoid being declared a carrier or an obligated party explicitly. > The model where the carrier provides DNS resolution is bogus and > obsolete for the reasons you cite. I think we are being to see a move in a different direction, where end users are no longer in a position to run resolvers. For me, that's not just theoretical because I've been forced to switch hosting providers because my current one filters DNS traffic to certain ISC.ORG name servers, apparently in an ill-advised attempt at prevent their customers from taking part in amplification attacks. > People are tired of being spied on without due process. Lets see some of > the Abu Ghraib torturers facing criminal trial. And more encryption helps with that how? Abu Ghraib would have been just another prison with an abuse problem without the pictures leaking out. Proper cryptography with extensive key management could have prevented that. It is difficult to predict how technology will be used. A decade or two ago, many of us thought that encryption and the ubiquity of software vulnerabilities (or the fallibility of information systems in general) would help to keep powerful governments in check. When I first sketched the technology that is now cited in quite a few DNS privacy discussions, I thought I was doing something genuinely helpful. Now the picture is less clear.
- [DNSOP] An approach to DNS privacy Phillip Hallam-Baker
- Re: [DNSOP] An approach to DNS privacy Florian Weimer
- Re: [DNSOP] An approach to DNS privacy Phillip Hallam-Baker
- Re: [DNSOP] An approach to DNS privacy Florian Weimer
- Re: [DNSOP] An approach to DNS privacy Phillip Hallam-Baker
- Re: [DNSOP] An approach to DNS privacy Stephane Bortzmeyer
- Re: [DNSOP] An approach to DNS privacy Phillip Hallam-Baker
- Re: [DNSOP] An approach to DNS privacy Florian Weimer