Re: [dns-privacy] [Ext] Threat Model

"Ralf Weber" <dns@fl1ger.de> Wed, 06 November 2019 09:24 UTC

Return-Path: <dns@fl1ger.de>
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 1F66B120C0F for <dns-privacy@ietfa.amsl.com>; Wed, 6 Nov 2019 01:24:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 6XSfFmmlrUFa for <dns-privacy@ietfa.amsl.com>; Wed, 6 Nov 2019 01:24:13 -0800 (PST)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 8706812095B for <dns-privacy@ietf.org>; Wed, 6 Nov 2019 01:24:13 -0800 (PST)
Received: by nyx.guxx.net (Postfix, from userid 107) id 9354F5F404CA; Wed, 6 Nov 2019 10:24:11 +0100 (CET)
Received: from [172.19.177.175] (unknown [46.183.103.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id E0C525F4035B; Wed, 6 Nov 2019 10:24:07 +0100 (CET)
From: Ralf Weber <dns@fl1ger.de>
To: Warren Kumari <warren@kumari.net>
Cc: Paul Wouters <paul@nohats.ca>, dns-privacy@ietf.org
Date: Wed, 06 Nov 2019 10:24:06 +0100
X-Mailer: MailMate (1.13r5655)
Message-ID: <FC51D8EC-5ADC-4415-82EB-C6C6E4E8D84A@fl1ger.de>
In-Reply-To: <CAHw9_iKhaA9Nb+eH92YfzdepU90_DgLyS-ZDaMAehKOFO0ksEA@mail.gmail.com>
References: <CABcZeBMQEJ=LE8ATQYnJj59srsK47hf4HT3BMMg3X2crVfSUXQ@mail.gmail.com> <CABcZeBOhSYvqPyDcm9zbMYRc03DmPcCKYTYE-uC54=Mm9HMcnQ@mail.gmail.com> <99ee8cd4-9418-2d64-57fd-487b4f2c3a1a@cs.tcd.ie> <CABcZeBOBFFi=dA_XEzhkYvRU6kzvND5CMQcMoyriYusDH0RbKQ@mail.gmail.com> <CAHw9_iLz5No-SKa74To03ida3DHfeKY58CrJFJpLph8FsvzNQQ@mail.gmail.com> <CABcZeBMFDbATVRvJvvs5b4giQ=0B82i76ahv-ffDgWJOzqZccw@mail.gmail.com> <CAHw9_i+e8veeAz+KYXjvchmjKJz6OZHX1pEYx_Tvs8n5xnfBnQ@mail.gmail.com> <6D6233DC-4D7C-45BC-9D4E-08E6E882C1A5@nohats.ca> <alpine.DEB.2.20.1911042035571.29247@grey.csi.cam.ac.uk> <CAH1iCioH86q1CX7A+F8ON4uzpGqipUy8m3iczyNqSKirAsYBQg@mail.gmail.com> <alpine.LRH.2.21.1911041652450.5093@bofh.nohats.ca> <CABcZeBOtY3saJe5DWTu=Jqy5guqdoKPKSR+XYddbvxwxKsxmig@mail.gmail.com> <CAHw9_iKaeT0VEjZfoCi9Nddc+VBBj0JHWDHv+=g3xzvb6L+Nvg@mail.gmail.com> <alpine.LRH.2.21.1911050941090.30046@bofh.nohats.ca> <CAHw9_i+MxMCd7dDO7N0-hc1SDjvBeoLoUvbg4JWDzXyjR0u4xQ@mail.gmail.com> <alpine.LRH.2.21.1911051437000.11602@bofh.nohats.ca> <CAHw9_iKhaA9Nb+eH92YfzdepU90_DgLyS-ZDaMAehKOFO0ksEA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/E_y4pSXD1F_GBzZK9kDxGtBm9M4>
Subject: Re: [dns-privacy] [Ext] Threat Model
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: Wed, 06 Nov 2019 09:24:16 -0000

Moin!

On 6 Nov 2019, at 0:13, Warren Kumari wrote:
> I'd like some system where I can signal that I support DoT:
> 1: without my parent having to do anything (like be upgraded to 
> support DoT)
Why does the parent to be upgraded to DoT? It can just indicate a DoT 
server for a child. These are normal DNS semantics.

> 2:  without having people to probe and wait for a timeout
Again resolution follows the delegation, so that is the best place to 
put this in.

> 3: with my users first connection protected, so they don't have to
> lookup safe.kumari.net (to make sure that the resolver knows that
> ns01.kumari.net supports DoT), or something like _dot.kumari.net
> before looking up secret.kumari.net.
Well as long as you are ok with that someone wants to something in 
kumari.net that should work. However maybe it is good to remind people 
that public DNS data is public so keeping something secret is hard to 
impossible. Also there has been some research presented at the ANRW 
workshop that even when hiding all DNS traffic from an observer it still 
is possible to digest what user visited by only looking at the IP 
addresses. ( https://irtf.org/anrw/2019/program.html - What Can You 
Learn from an IP). As said before if we really want privacy for users we 
have to fully encrypt and obfuscate layer 3.

> 4: without expecting everyone to support DNSSEC.
Really. I can not see how we design something new that does not take 
DNSSEC into account. That would negate a lot of hard work done by a lot 
of people over decades. Would you design something new without taking 
IPv6 into account?

So long
-Ralf
—--
Ralf Weber