IETF Logo Mail Archive

Re: [dns-privacy] DNS over HTTPS via HTTP proxies

Martin Thomson <mt@lowentropy.net> Mon, 19 July 2021 04:46 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 829ED3A21CD for <dns-privacy@ietfa.amsl.com>; Sun, 18 Jul 2021 21:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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=fPGH7s+q; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VHoj4GQU
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 jNR-76bhl8sF for <dns-privacy@ietfa.amsl.com>; Sun, 18 Jul 2021 21:46:48 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD2623A21C7 for <dns-privacy@ietf.org>; Sun, 18 Jul 2021 21:46:48 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id A5FD15C0079 for <dns-privacy@ietf.org>; Mon, 19 Jul 2021 00:46:47 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute5.internal (MEProxy); Mon, 19 Jul 2021 00:46:47 -0400
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 :subject:content-type; s=fm2; bh=SU7VBDtuenJouk471hYjLCICyAQ0N4t i5E/brNRIhbw=; b=fPGH7s+qJCN3LGHhtEr5/7OARZmMclP40eu7HBbOyGb9Ikg 89wMWT32hXkNrRX1myAV4J2DGmNRvLfnnTUqWjYBcuUR5g1HyfwdoNm2ExLXM7+Z /WYJlfzCdbL0PDALjIg8V+4u40GYw/bKmsYJ6sZU/YOPRgi2IUR5aXEvT4ukY9WT 8i01BGx8xGThmYAHblLz7/mDC3jbEqh/NhZmN/nE3dwuVe8IY9VL9p0q7JVEiOrB QQ6kcRN9NXDq0xf2h8EashlR1Y+g15n/QQRqG0nyifaCtdCtfvuxdzMiDmqoybrq kz3kRO9dMU2hvf8Qnkq7x/QIdQc2oI4d/c9z9GA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=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=fm3; bh=SU7VBD tuenJouk471hYjLCICyAQ0N4ti5E/brNRIhbw=; b=VHoj4GQUqgAMY06ajRhmBC IEXwoD8siG4GFq4Oe3yP2OxaxXECYIc+PQWM0ioREtyHc9uou1MPTtsz0hpg+FDk oQ7I9lbaJfipIFPiwxYS2HCouPVE0dFJ4BN9NksfWIc6r8tuItMA9mtwqdIZXK44 ZZAzcNReDyAxrwdgejilpokfX8Yxl/HWIDQK+NHK9goga5kl8NFFy3B3v8TtSIi0 HF0xfq6wxGCJLqVJVMktBy/9xBuv+r51mktmEjw7nvnbw4ONwX32Jh66reJqx4p9 4CYJs1CVKX8N4rI39g+5DRI2ba6pkRuwDhe6kuWljr4yXD64oHh1Z/H6Kp0mz3XQ ==
X-ME-Sender: <xms:twP1YCX-NpHRosn8intuuSheu7rw3GOOU98YuNph04PNRT1e1EkLyQ> <xme:twP1YOmP0eTM5K2rJa1H_cWrB5vz3SM-n2oCvgm5R0ZyQUNW9dKzcTFAdTcNMocMm _3NWtAZQN3RaN0EXaI>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdelgdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepveekheehteevgfefvdegtd fgfefhkeeugfejgfejfeegffekteffffejhfevveejnecuffhomhgrihhnpehivghtfhdr ohhrghdpughnshdqohgrrhgtrdhnvghtpdhhthhtphhshhhofigvvhgvrhhithguohgvsh hnohhtphhrohhpohhsvghnvgifphhrohhtohgtohhlshgrnhgunhgvfihprhhogiihshho fhhtfigrrhgvrdhithdphhhtthhpphhrohighihinhgrphhplhhitggrthhiohhnshgsrh hofihsvghrshdrshhofhhtfigrrhgvpdhjphhrshdrtghordhjphenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhoph ihrdhnvght
X-ME-Proxy: <xmx:twP1YGb0sWTAhe-BnFQZkwDTlmN3BOAOB7z5up7uzCJSpFLi9sFWtw> <xmx:twP1YJUfRMgU7YIgrXWF4T81GWgPD7eikCpAkJ2UI_6k5RzpdLzdOw> <xmx:twP1YMkUAQl0mqIYNJKLv9T70hn8ZqRD92lQeOdpBmd0b-VETDO7kw> <xmx:twP1YIwomSJgOT6q7-yU3DHhE5ZhWv8llp-EW3fbVa7kSM-eNx9KWw>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5D35C3C0E6C; Mon, 19 Jul 2021 00:46:47 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.5.0-alpha0-533-gf73e617b8a-fm-20210712.002-gf73e617b
Mime-Version: 1.0
Message-Id: <01550c55-4d4c-48a8-bf5f-c0263d7c4d10@www.fastmail.com>
In-Reply-To: <20210719.130020.1116859977665651658.fujiwara@jprs.co.jp>
References: <20210719.130020.1116859977665651658.fujiwara@jprs.co.jp>
Date: Mon, 19 Jul 2021 14:46:27 +1000
From: Martin Thomson <mt@lowentropy.net>
To: dns-privacy@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/DIcZDGywqRIKivosI2kREwQDbf8>
Subject: Re: [dns-privacy] DNS over HTTPS via HTTP proxies
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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: Mon, 19 Jul 2021 04:46:55 -0000

Hi Kazunori,

I don't know if you are aware of this, but there is discussion about forming a working group for something like ODoH: ohttp@ietf.org is the mailing list.  This - just like oblivious DNS more generally - is aimed at providing one additional privacy feature that your proposal does not: that of longitudinal privacy.  That is, it aims to ensure that DNS resolvers aren't able to assemble profiles on people based on the set of queries they make.  As deanonymization techniques are surprisingly effective, the hope is that this would go a long way to break up query flows, while avoiding added latency and overhead.

An HTTP proxy can be used in a way that breaks linkability, but it costs a lot of time and CPU.  The TOR model has the same query linkability issue and even worse performance.  The HPKE-based design in OHTTP (which is fundamentally the same as Oblivious DNS/DoH) trades performance for replay risk.  As DNS queries are naturally pretty resilient to replay, this seems like a pretty good deal.

On Mon, Jul 19, 2021, at 14:00, fujiwara@jprs.co.jp wrote:
> People who interests stub resolver's privacy,
> 
> I submitted new draft "DNS over HTTPS via HTTP proxies" last week.
> https://datatracker.ietf.org/doc/draft-fujiwara-dprive-doh-via-httpproxy/
> 
> It is a rewrite of the OARC 35 presentation.
> https://indico.dns-oarc.net/event/38/contributions/858/attachments/798/1467/doh-202105060305.pdf
> 
> It relates to Oblivious DNS over HTTPS, however, it does not propose
> new protocols and new proxy software.
> (it uses HTTP/1.1 CONNECT Method.)
> 
> I will be happy
> if some providers offer "open HTTP proxies for DoH providers"
> and application software developpers implement "DoH via HTTP proxy"
> in applications (browsers).
> 
> # Software needs two proxy settings for DoH and other HTTP targets.
> 
> Regards,
> 
> --
> Kazunori Fujiwara, JPRS <fujiwara@jprs.co.jp>
> 
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

v2.23.0 | Report a Bug | By Email