Re: [dns-privacy] Some additional signalling ideas
Paul Wouters <paul@nohats.ca> Sun, 31 March 2019 20:38 UTC
Return-Path: <paul@nohats.ca>
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 EF8361201C3 for <dns-privacy@ietfa.amsl.com>; Sun, 31 Mar 2019 13:38:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
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 PDM14E1DFxEc for <dns-privacy@ietfa.amsl.com>; Sun, 31 Mar 2019 13:38:52 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CFF120003 for <dns-privacy@ietf.org>; Sun, 31 Mar 2019 13:38:52 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44XS4B1Q2pz3Bv; Sun, 31 Mar 2019 22:38:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1554064730; bh=0NQJfDk1hWmRpzDWNSkBcUhSsPRyZ7H8uacd2LmZhVE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=K1JRkZSINywl3NyStoHwFrQfDR7iQ7bpRvKA4RJj72JgYfG/TpHasEvEpPzzmRv7X HvZ5vDaU/kI/7nYf4W3OYeSrW8jovTb0NjoSCGivv3J8m2C+TKWHRakA9Vz25BnCl5 ZdbqXfHxM6UJIAVtF1wWvn3xX7oeGZC5wRU8xZos=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wT3JmNx_vmad; Sun, 31 Mar 2019 22:38:48 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 31 Mar 2019 22:38:47 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id E36FAA622C; Sun, 31 Mar 2019 16:38:46 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E36FAA622C
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D4A9340D358A; Sun, 31 Mar 2019 16:38:46 -0400 (EDT)
Date: Sun, 31 Mar 2019 16:38:46 -0400
From: Paul Wouters <paul@nohats.ca>
To: Watson Ladd <watsonbladd@gmail.com>
cc: dns-privacy@ietf.org
In-Reply-To: <CACsn0ck-SNweieak5Fn7TOLLZTvsQNo6+w3nezxKuZPq0Z4QNA@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1903311629390.16270@bofh.nohats.ca>
References: <CACsn0ck-SNweieak5Fn7TOLLZTvsQNo6+w3nezxKuZPq0Z4QNA@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/D7OZY77r83RJXjfcxe-WMDXd_X0>
Subject: Re: [dns-privacy] Some additional signalling ideas
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: Sun, 31 Mar 2019 20:38:55 -0000
On Sun, 31 Mar 2019, Watson Ladd wrote: > Please rip these ideas to shreds: > 1) An extra bit in a response for "you could have asked over TLS" Too late, you already lost your privacy. > 2) An extra field when looking up the nameserver for "you can ask > that server over TLS" Where would this field be? Not a DNS option because that would take 10+ years to roll out. also how would this option be secured? > 3) An extra field/bit/convention for "this nameserver supports tls" > (like tls-ns vs ns) Same as above. There was a reason I somewhat joked about DNSKEY flags. It is one of the view signaling methods we have that is secure and is about publishing something at the parent on behave of the child. But I don't think this is a real solution either. It would be a very bad signaling hack. The trick will be to have nameservers that are not within bailiwick of the zone. Then if the parent's transport security was good, you get nameservers which you can query for TLSA or tls-dnssec-chain to get its TLS/HTTPS key. Then query it for the target domain zone. And at that point you do not need a flag anywhere else either. And knowing you are querying ns.bighoster.com shouldn't reveal which domain you are looking up specifically. All of this assumes query minimalization too (obviously, if you do not, then you leak the target domain all over the place) It also leaves the domains with bailiwick without protection, but those target domains should only be hosting NS/A/AAAA of nameservers so the privacy loss is minimal. Paul
- [dns-privacy] Some additional signalling ideas Watson Ladd
- Re: [dns-privacy] Some additional signalling ideas Ralf Weber
- Re: [dns-privacy] Some additional signalling ideas Ilari Liusvaara
- Re: [dns-privacy] Some additional signalling ideas Watson Ladd
- Re: [dns-privacy] Some additional signalling ideas Paul Wouters
- Re: [dns-privacy] Some additional signalling ideas Alexander Mayrhofer
- Re: [dns-privacy] Some additional signalling ideas Stephen Farrell
- Re: [dns-privacy] Some additional signalling ideas Alexander Mayrhofer
- Re: [dns-privacy] Some additional signalling ideas Tony Finch
- Re: [dns-privacy] Some additional signalling ideas Peter van Dijk
- Re: [dns-privacy] Some additional signalling ideas Ilari Liusvaara
- Re: [dns-privacy] Some additional signalling ideas Ralf Weber