Re: [dns-privacy] Alternative signalling propsals
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 15 December 2018 01:06 UTC
Return-Path: <dkg@fifthhorseman.net>
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 F1687130F14 for <dns-privacy@ietfa.amsl.com>; Fri, 14 Dec 2018 17:06:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 MitwgLMjr9sy for <dns-privacy@ietfa.amsl.com>; Fri, 14 Dec 2018 17:06:09 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B77DE12E036 for <dns-privacy@ietf.org>; Fri, 14 Dec 2018 17:06:09 -0800 (PST)
Received: from fifthhorseman.net (unknown [38.109.115.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id ACCEEF99D; Fri, 14 Dec 2018 20:06:07 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id A43D320867; Fri, 14 Dec 2018 19:37:04 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, "Reed, Jon" <jreed@akamai.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
In-Reply-To: <f8e17058-f769-ff2d-95f6-9b8850f5fbaa@cs.tcd.ie>
References: <74C380A3-C69F-4340-A723-B134F052953E@akamai.com> <f8e17058-f769-ff2d-95f6-9b8850f5fbaa@cs.tcd.ie>
Date: Fri, 14 Dec 2018 19:37:01 -0500
Message-ID: <87sgyz1v82.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RaElKNQ_YEVC3wbRmmy20uJ22FE>
Subject: Re: [dns-privacy] Alternative signalling propsals
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Sat, 15 Dec 2018 01:06:12 -0000
On Fri 2018-12-14 22:58:09 +0000, Stephen Farrell wrote: > I'm probably exposing my lack of DNS-clue, but I wonder if it > is/isn't possible to embed a "like/want/offer privacy" signal > in the DNS protocol, rather than in the data carried by the > protocol? (Regardless of whether the latter might be done via > funny names or new/additional RRs.). i think you're suggesting some sort of "starttls"-like mechanism -- start a DNS connection to an authoritative server, and then the server lets you know "hey you might also want to try me in the future via private channels" is that what you're proposing? if so, it has the unsatisfying aspect common to all starttls-like proposals: it can be trivially stripped. it is also unsatisfying in the DNS world because there typically isn't a handshake -- the first packet contains the sensitive data that you might want to keep private. It could certainly help over the longer term against a passive monitor -- the initial privacy leak could be amortized over many future communications between the resolver and the authoritative -- but it still leaves the first connection to that server unprotected even against passive attack, which is something that signalling in the name could potentially avoid. --dkg
- [dns-privacy] Alternative signalling propsals Reed, Jon
- Re: [dns-privacy] Alternative signalling propsals Warren Kumari
- Re: [dns-privacy] Alternative signalling propsals Jon Reed
- Re: [dns-privacy] Alternative signalling propsals Warren Kumari
- Re: [dns-privacy] Alternative signalling propsals Paul Wouters
- Re: [dns-privacy] Alternative signalling propsals Stephen Farrell
- Re: [dns-privacy] Alternative signalling propsals Daniel Kahn Gillmor
- Re: [dns-privacy] Alternative signalling propsals Daniel Kahn Gillmor
- Re: [dns-privacy] Alternative signalling propsals Stephen Farrell
- Re: [dns-privacy] Alternative signalling propsals Mark Andrews
- Re: [dns-privacy] Alternative signalling propsals Wes Hardaker
- Re: [dns-privacy] Alternative signalling propsals Paul Wouters
- Re: [dns-privacy] Alternative signalling propsals Warren Kumari
- Re: [dns-privacy] Alternative signalling propsals Tony Finch
- Re: [dns-privacy] Alternative signalling propsals Wes Hardaker
- Re: [dns-privacy] Alternative signalling propsals Petr Špaček