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.