Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh

Tomas Krizek <tomas.krizek@nic.cz> Thu, 18 March 2021 16:20 UTC

Return-Path: <tomas.krizek@nic.cz>
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 2F1473A2EF7 for <dns-privacy@ietfa.amsl.com>; Thu, 18 Mar 2021 09:20:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 qN05lGcMmf_a for <dns-privacy@ietfa.amsl.com>; Thu, 18 Mar 2021 09:19:59 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 D4B913A2ED7 for <dns-privacy@ietf.org>; Thu, 18 Mar 2021 09:19:58 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:80cf:1dff:fe11:7307] (unknown [IPv6:2001:1488:fffe:6:80cf:1dff:fe11:7307]) by mail.nic.cz (Postfix) with ESMTPSA id 92A66140B7D; Thu, 18 Mar 2021 17:19:51 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1616084392; bh=/JUEiRyC1qmED8RQVxLaOzjQz8M8/p4V1NZnWu4yD54=; h=To:From:Date; b=K2Z3qWKNOA2nQuizk1BwUXptSVbevpvIXlY6g9/4cpc5tz2tYzttmx9TrdT4cxKPY 4wu3IcOGFwlogGbpCfYR63/GljTcsrga8OZQ6Y+BQ8iwcX5z9Ezi+9YT3fmNHrvB1c KZibht0zlCx8Mv36eHKpCpYfRhI7hBk6dkKZwOb0=
To: Tommy Pauly <tpauly@apple.com>, Eric Rescorla <ekr@rtfm.com>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
References: <1a1ef163-bef8-0726-8e51-e444e8fe6091@innovationslab.net> <86e54685-ab6e-83b5-e4f6-bbd71fc6dd5a@nic.cz> <CABcZeBOgE=ABFwErsYFrjSRWFXgcJp_JncVXbwcaiDf3iFs7RA@mail.gmail.com> <AF91913A-42A1-4832-8113-F576C4AA4684@apple.com>
From: Tomas Krizek <tomas.krizek@nic.cz>
Message-ID: <76434da1-4d38-5a07-3e92-acfea485b449@nic.cz>
Date: Thu, 18 Mar 2021 17:19:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <AF91913A-42A1-4832-8113-F576C4AA4684@apple.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="E6PkiYRRFi8lKsqaex0yaZ2jVUGFcN6RR"
X-Virus-Scanned: clamav-milter 0.102.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/YGZM8fxZ2rukI9Ba5viJ27vMQ_4>
Subject: Re: [dns-privacy] WG Call for Adoption: draft-pauly-dprive-oblivious-doh
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, 18 Mar 2021 16:20:08 -0000

On 18/03/2021 16.42, Tommy Pauly wrote:
> 
>> On Mar 18, 2021, at 8:32 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> On Thu, Mar 18, 2021 at 5:02 AM Tomas Krizek <tomas.krizek@nic.cz <mailto:tomas.krizek@nic.cz>> wrote:
>> I oppose adoption.
>>
>> The draft introduces huge amount of additional complexity, both for
>> implementors and operators of DoH. This raises the bar for both smaller
>> vendors and operators, thus leading to more centralization.
>>
>> This seems like an odd argument. We shouldn't do something that's
>> a manifest increase in privacy (even as experimental!) because it's
>> work to implement?
> 
> I would also point out that no one is asking that generic recursive resolvers implement this strategy, not only because it would be experimental. Certainly there would be no expectation that all DoH servers support this. Instead, cases where clients are particularly concerned about revealing client IP and identity to very large public resolvers benefit more from this. The intent of having an experimental RFC is to have a common way to achieve that goal.

I'm just pointing out that due to the complexity of both supporting and
operating such setup, only very few implementations and very large
providers could use it.

Since the draft doesn't address the underlying issue for DoT or DoQ and
might be subject to be obsoleted in the future by OHTTP, I think work to
improve privacy is better spent elsewhere.
-- 
Tomas Krizek
PGP: 4A8B A48C 2AED 933B D495  C509 A1FB A5F7 EF8C 4869