Re: [DNSOP] An approach to DNS privacy

Florian Weimer <fw@deneb.enyo.de> Sun, 09 March 2014 14:26 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 C8D701A0236 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 07:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.198
X-Spam-Level:
X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 U_vzrq7IWLP7 for <dnsop@ietfa.amsl.com>; Sun, 9 Mar 2014 07:26:39 -0700 (PDT)
Received: from ka.mail.enyo.de (ka.mail.enyo.de [87.106.162.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5A4E51A0233 for <dnsop@ietf.org>; Sun, 9 Mar 2014 07:26:39 -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 1WMegR-00043H-Ve; Sun, 09 Mar 2014 15:26:32 +0100
Received: from fw by deneb.enyo.de with local (Exim 4.80) (envelope-from <fw@deneb.enyo.de>) id 1WMegR-0005br-Qf; Sun, 09 Mar 2014 15:26:31 +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>
Date: Sun, 09 Mar 2014 15:26:31 +0100
In-Reply-To: <CAMm+LwhH0Zq-Adok8YxDkHAUA+ga7eTLnyXAGxee=h8RivSm0g@mail.gmail.com> (Phillip Hallam-Baker's message of "Sun, 9 Mar 2014 09:27:09 -0400")
Message-ID: <87r46b78iw.fsf@mid.deneb.enyo.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/Ft-6wcEov9F7a5hNFz_yIo749lE
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:26:42 -0000

* 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.