Re: [DNSOP] An approach to DNS privacy

Phillip Hallam-Baker <hallam@gmail.com> Sun, 09 March 2014 14:54 UTC

Return-Path: <hallam@gmail.com>
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 38C611A0360 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 07:54:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 iYfv6CostKaK for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 07:54:40 -0700 (PDT)
Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 21DED1A0361 for <dnsop@ietf.org>; Sun, 9 Mar 2014 07:54:39 -0700 (PDT)
Received: by mail-lb0-f173.google.com with SMTP id p9so3947935lbv.4 for <dnsop@ietf.org>; Sun, 09 Mar 2014 07:54:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rR3l9CIuseGEYsxVkMH2Rm8snrSSo9QqBYSBisBS7Vk=; b=JcOenLWU+1s8WLmbsM9vtJQVFutne4WFrS+A9lR+jDhOHlkWIE7vQEEtCEknfG2+LI 2mSfQleVkwOA/pwTH5mpute8+E2agcgHTjTEsseOzYyCJdPzvLKEktnPcXzFB7POtG4P 33MfoomVwe/JypF4NJHZ00YRsGeY/vPP8sRugUeH60YAAoQG09WobhYDLnDh2tUTrwiw ACB5R1wPCfJqEk8b8/XrOy9FHXMWPR9Bm9DB9rMZRwzh0mPAJNVENmS5hfPpdW5aL1sb KxQdPZD0XAWqlq1yGG+4SBk9wvcu4+9dNR55MmGbmGsYg9PkHM3r0pORV5nEMD+69pIS DO7A==
MIME-Version: 1.0
X-Received: by 10.152.42.196 with SMTP id q4mr11714617lal.14.1394376874525; Sun, 09 Mar 2014 07:54:34 -0700 (PDT)
Received: by 10.112.37.168 with HTTP; Sun, 9 Mar 2014 07:54:34 -0700 (PDT)
In-Reply-To: <87r46b78iw.fsf@mid.deneb.enyo.de>
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>
Date: Sun, 9 Mar 2014 10:54:34 -0400
Message-ID: <CAMm+Lwid7ciEXXNEbXjXatsfYa1iSrpiN8vAT-_QifSp5z9uVg@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Florian Weimer <fw@deneb.enyo.de>
Content-Type: multipart/alternative; boundary=001a11c34e8e4a084704f42daa70
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/IGb9xuT6mtDEjmwzxWAs88DVZx0
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, 09 Mar 2014 14:54:43 -0000

On Sun, Mar 9, 2014 at 10:26 AM, Florian Weimer <fw@deneb.enyo.de> wrote:

> * Phillip Hallam-Baker:
>
> > But first, cite actual legal authority because I don't believe your
> > interpretation of the law is remotely correct.
>
> § 8 Abs. 3 TKÜV:
>
> | Wenn der Verpflichtete die ihm zur Übermittlung anvertraute
> | Telekommunikation netzseitig durch technische Maßnahmen gegen
> | unbefugte Kenntnisnahme schützt, hat er die von ihm für diese
> | Telekommunikation angewendeten Schutzvorkehrungen bei der an dem
> | Übergabepunkt bereitzustellenden Überwachungskopie aufzuheben. [...]
>
> | If the obligated party [the organization to which these rules apply]
> | uses technical measures at the network layer to protect submitted
> | communications against unauthorized disclosure, it shall revert the
> | protections on these communications for the surveillance copy
> | provided at the handover interface.
>
> U.S. law is similar (47 U.S. Code § 1002 (b) (3), if that citation is
> correct):
>
> | A telecommunications carrier shall not be responsible for
> | decrypting, or ensuring the government's ability to decrypt, any
> | communication encrypted by a subscriber or customer, unless the
> | encryption was provided by the carrier and the carrier possesses the
> | information necessary to decrypt the communication.
>
> 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.

The model where the carrier provides DNS resolution is bogus and obsolete
for the reasons you cite.

People are tired of being spied on without due process. Lets see some of
the Abu Ghraib torturers facing criminal trial.


-- 
Website: http://hallambaker.com/