Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03

"Martin Thomson" <mt@lowentropy.net> Thu, 09 January 2020 02:06 UTC

Return-Path: <mt@lowentropy.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 6E6FE120639; Wed, 8 Jan 2020 18:06:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=D3CmP7uD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AQ4Ed+14
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 APZj4RJYUBAj; Wed, 8 Jan 2020 18:06:26 -0800 (PST)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10E16120233; Wed, 8 Jan 2020 18:06:26 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2A646999; Wed, 8 Jan 2020 21:06:25 -0500 (EST)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 08 Jan 2020 21:06:25 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=MxcgKlpUDKqEW0/+/EmXEp4baidV a+Een/qjtxiNPqg=; b=D3CmP7uDbW/mf5QDy5YyiXYn8i/Rkf7RbfH1hXSeTU6m SKPFHPeocBsrbwzFinR8wKy96HDkhth2nJnalnD9y+FGGkfBV+caz5Tw5NLbDENC 0HDN/r2ryRW5g3lkNbDwghGjlBviPPm+6Wd8yma4FaSvEIwyWnlR8V44Uq6Ys9Wa +dqOleFjohKKsSgxUxdP7ScNpnmkbjGZZOffNudY3lBXt47+F2bpAbyga9AvIxHC zeALPjOOgVlcTtwi6sSq6sHvHWEF4TxZMHJxii1+9iACBCLunxODlxTSPt5slrPT XKkEEihUyFYc6EowZ7SkJvaRHPxvE3fXILPlzlUxgA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=MxcgKl pUDKqEW0/+/EmXEp4baidVa+Een/qjtxiNPqg=; b=AQ4Ed+14bwzq7o9GC/r4FC Nt6/Qnv9wNuyd1wBqd3f22bcATEPMADKAJyGtAqJNPpmdniWJ+MSFyD+rKMBISOB W1M/6XYa7Tu1FnWIfQ03eTXSeCtOCjB2TMT4OSW7cj8A7JDSJXsxnCBcC5AGvRXk 2P2OQ/swUO7muBzZY8RAFcrfrKd8/SpLvF6J/EVsOOVdfr7gmJIpCLPF/9gDa60j R6Ug5oRJgrlxEma1e3DuPal2/Z8YVJS8hr1Gn2uoB5q2cZPNaSKuSszCUd8xmeNM 2JoKx6zCIVCXOdHujima3rkt/6AXuB2ULykP1Ww48lKELLCWyX8PmkH8brIJXetg ==
X-ME-Sender: <xms:oIoWXn3BbhuSqiKwwW0lwxU8gOiyDH0HgXz25a9NEKOK1yEGBV_h5w>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehledggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecurf grrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehl uhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:oIoWXu4fTky57-0x0Q6SZug9-k75USPjuOF8nYgNKv7QtF-QaMTT5w> <xmx:oIoWXu0mMIO_-MLbhmEleGYrtMYymfiBOsnnBLC-2KpLWI-4nzwg8g> <xmx:oIoWXma2aFESMOop_iFkmQquGmrCP0xrFjgsDTZO4Riyt9fdv0wZrQ> <xmx:oIoWXghpz94ayiSi8LO_V_S4JtjazpwjSGqe5GaNK_eGZHdJcxoieg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 3F79EE00A2; Wed, 8 Jan 2020 21:06:24 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-731-g1812a7f-fmstable-20200106v2
Mime-Version: 1.0
Message-Id: <cca5f51f-a1de-4a29-a048-3dd9aea326fc@www.fastmail.com>
In-Reply-To: <CABcZeBON_ADPXvim_Q6TUSqp-12ii2Gm3y55Oc0CGhqSQqc_kQ@mail.gmail.com>
References: <4639bd67-6fca-47d1-aaeb-85fcd0394f46@www.fastmail.com> <029D8BB9-CE93-486A-BDF2-6D0720E59109@sinodun.com> <18c8c298-e462-490b-b3a3-5d5904d98c25@www.fastmail.com> <18F59166-83B9-4402-8703-B90589B540F5@sinodun.com> <01b7df16-7917-4251-8daa-550262ce5461@www.fastmail.com> <CAChr6SwpPnBo0uf5+XJw7c998TgjDyQMdoD6g0OKwOBD9+JQ3Q@mail.gmail.com> <CABcZeBON_ADPXvim_Q6TUSqp-12ii2Gm3y55Oc0CGhqSQqc_kQ@mail.gmail.com>
Date: Thu, 09 Jan 2020 13:06:05 +1100
From: Martin Thomson <mt@lowentropy.net>
To: 'Eric Rescorla' <ekr@rtfm.com>, Rob Sayre <sayrer@gmail.com>
Cc: last-call@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, Sara Dickinson <sara@sinodun.com>
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/v9l9c8EvPCSLzR8TTf0KtogZri0>
Subject: Re: [dns-privacy] Review of draft-ietf-dprive-rfc7626-bis-03
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: Thu, 09 Jan 2020 02:06:27 -0000

On Wed, Jan 8, 2020, at 23:51, Eric Rescorla wrote:
> On Tue, Jan 7, 2020 at 8:28 PM Rob Sayre <sayrer@gmail.com> wrote:
> > Couldn't servers give out unique URI templates?
> 
> DoH doesn't specify how the clients get the templates. At least for a 
> Firefox-style TRR program, what you describe can't happen because there 
> is a single fixed template.

It is true that the potential for providing individualized endpoints for tracking purposes is an exposure.  In discussing 7710bis, we identified this as a risk of DHCP specifically.  IPv6 RAs by their nature generally don't have this problem, though I'm sure a network might be built in such a way as to add that capability.  Provisioning domains do.

In the new work we are likely to undertake, this is something we'll have to consider, but I don't see it as a huge issue: if you are deferring to another entity for discovery without prior expectations about what you will get, there are many ways to get into this sort of pickle.  That is, in the context of pre-existing DNS discovery, I don't believe that this creates a new exposure to this style of attack.