[Doh] some privacy ponderings wrt HTTPs and plain DNS

nusenu <nusenu-lists@riseup.net> Mon, 18 June 2018 23:29 UTC

Return-Path: <nusenu-lists@riseup.net>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBB2130E55 for <doh@ietfa.amsl.com>; Mon, 18 Jun 2018 16:29:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net
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 8RYf9hKdY8Sl for <doh@ietfa.amsl.com>; Mon, 18 Jun 2018 16:29:42 -0700 (PDT)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BF7F130DBE for <doh@ietf.org>; Mon, 18 Jun 2018 16:29:42 -0700 (PDT)
Received: from cotinga.riseup.net (cotinga-pn.riseup.net [10.0.1.164]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id 1B9011A0D12 for <doh@ietf.org>; Mon, 18 Jun 2018 16:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1529364582; bh=6E4sFc5iuxMLi1kqcvxb4FhSxON3PVvcZRB+jYWdkGs=; h=From:Subject:To:References:Date:In-Reply-To:From; b=HTcAwpisTFROwBzQKK7KQc87z1PpM6npsDbqNXRjIRnDiMVBZI7GstdzqnkITW4gr xTUaZOrekJw2Maf+x3jaVGzYO8k+9yGbMxKsyM913AsJNQ3biIcXeg9D/M2hHFy50k ABKIQvgn55oxNDHEuqU0AqL28GsOyj7wW4/PupIM=
X-Riseup-User-ID: F140D8EBA0C557ED64777C50AD302A399FC2C86CB472D2A596DBCDEE99F6A0C6
Received: from [127.0.0.1] (localhost [127.0.0.1]) by cotinga.riseup.net with ESMTPSA id 42CC6C70D0 for <doh@ietf.org>; Mon, 18 Jun 2018 16:29:40 -0700 (PDT)
From: nusenu <nusenu-lists@riseup.net>
To: doh@ietf.org
References: <20180618112116.GB9195@server.ds9a.nl> <BYAPR19MB22487DA7854991C84B66B47A94710@BYAPR19MB2248.namprd19.prod.outlook.com>
Openpgp: preference=signencrypt
Autocrypt: addr=nusenu-lists@riseup.net; prefer-encrypt=mutual; keydata= xsFNBFj53gUBEADYKwT0pW1yiqt6UReZW8T2nXVCyeVT2G6z7AvW69afp82uthRH237pQ7Qs 5vq91DivN6fGN6cVksp0N9Yv+5HEQAwUxpLfcNDcGzmHMd0JMItEtozGv3a4FuiUoHAqeGXM 6Kzi3v5F2PZGF+U4QaGKEZq6u50gO/ZFy4GfC9z9tsO6Cm7s7KldVHMGx/a0MEGMwh6ZI9x2 hGXSSAKu58KRUkEpHzDiQTj+/j58ndNfZRQv6P5BLppHADRPqwEOm4RQcQYskyM0FdKXbJ8E 5GW268meflfv2BASsl3X/Xqxp+LNrstXIbFZ+38hVlQDDmdvaASpPTzIAxf8FxMYZqI+K1UE kP5nU45q84KiZoXwT6YYJDKToLSDnYkKlsrCSnLkE3Nb/IexgNoYO4nE6lT9BDV3athQCWw1 FwB5idRYWnIqbVgUFgYZDUdZBJmeTEeI+Wn5hFz6HvFVc/+haMVTcoEKSkG/tsSGsKOc2mp6 z+71io9JWrVQGmw7OeZeE4TvkF9GhwS8jrKO4E0crfcT/zT6368PZCO6Wpir8+po/ZfOWbbh 1hi3MxmXn4Fki55Zrvhy3sf28U+H/nByQV4CssYv/xVhIZsN/wNQLcDLgVs4JTBUik8eQR0Y Qrq9lG3ZVtbpEi7ZTJ6BOGIn2TKHsVIVGSQA0PdKpKYV45Lc4QARAQABzSBudXNlbnUgPG51 c2VudS1saXN0c0ByaXNldXAubmV0PsLBfQQTAQgAJwUCWPneBQIbAwUJBaOagAULCQgHAgYV CAkKCwIEFgIDAQIeAQIXgAAKCRCtYTjCRc1Cfq/kD/sHx+mnL6OLwJvBj1rVTyoHJYJARajz Go0yRlbrZSH6Z05OD3SDR9UVpWOZeY8JyFoTyCFQjAbIVjKifj0uSmi0j1iahrAgGGfik0cN XUkCxrW6jcJQ37EbvYWu4PryqLuC7IeQW1wCcB1ioyGYKkm2K6LZ9rzZPVYSmPohJ+gVI0Jt EdlNZl4JuZot9eA5w/22uvcStQHzXDsUxfqK8OAJpU8E3iBBdNpLPMDWpFz4g2yw5PD6jZ+K Q39PYMUFULaKe4YCw1O+0MFhZJI4KEcRYHuVy1b3cJjxzgVfEyFctLDsO1sh07vBhoVKUi8W e00pvGtv8QYxxMYIA3iACbsjGEr69GvvZ2pAnu9vT9OUCaES4riDCxbkMxK/Cbwk8F6mo0eq HDQ7sOZWQv81ncdG9ovlA7Pj96cEXgdtbbllF1aUZ8sAmT14YjGzhArGv7kyJ1imH5tX3OXk hBGA9JTk2mDNjEpFaTEajSvDiKyeEhWNTLm15siWkpg1124yjUkhQ3OCkw7aUDMiVn8+DQHo J2pP/84uUvngbhm1jV7nk8mxTUFgppUePkb5hhnRRzeK72QY00EwRdn7qnpNgijMJ3Fpjfy2 EeCEl3nNdcB7U0F+0ijA6P/+DROldxNr4eiP50RvV8XiW/yi2IkKBk50GNB87yYnDETxxx/c 2i00AM7BTQRY+d4FARAAwJZ6U7UT8uB1WCfLK3AOR1Wa9bzOAghlTR4WXbHB4ajQKG7/Fzud 99bnwD0V3/AOVz/SbGDyHe+7HMvd1A0Ll4NgyH6OpxY7wOwCXAYTAbcXLpM7eKTjjsb9A9XG 3FcIGvjcy76OkaewqhiABaShlStEYcPkRusHZuecXtCnfCjJKihU/kinWpBO9gY6SrF2KFCw aeS4r37brXQ9y8uy3gZ168QFuIa5AKfL0r5YN3k4StNSA2p5Z/pufWXMN3B03QC+3fireiz3 dinlHK6XjUW8oWSdNxJhexT/lUw+episNuWTQruy7PD+HeohYGXqjggmPUiWc171Sewb2f8H CHViHMee8QXqo/LSRkYVrtsx0HUSMKsVQOma/u2By03ucroIkQJQQfqX3YpK1i3EpUO2L0/m E8UpBvUm1vrst54EFym4tYNJTj9reVffFKh2cczmPVN5o8v3RrdTF96mGtcb9EJbGV4277ZE LqUspviEBXynqU3yZ48JhIWHj22/ha6TeBpapYZDOJ8lePed8E34J/GYE2YXl65LhpXAKvWz O3KiByGMysb9Li6zqZ9/BYQtg5CA6Q8Oo7pBxK4iiDH3GX2WvymmLoaOBpOaIYdvKr39fajE mzfbg7TdZKXxqp2KDrbw7vUJLDyrmPWpxHyhKHItzoi1Y59wzYSq3h0AEQEAAcLBZQQYAQgA DwUCWPneBQIbDAUJBaOagAAKCRCtYTjCRc1CfpfgEAC3tXZzhgKbF6fx5gMNDp/9MBpialvu k69UaGL3HUqM0/ytiT4FjYUmOK2mk37iop46GivsOC50PykG9gjbg9/QKUqgsZzJ8LJ+ldY4 /GKtiP5JoO59Obj8MJJ5Ta8yPfZiiNx/I8ydqd18E4PmQUCPlEKhett81t3+8R/mGwG72TaA hHwDjZAEjiXdnXh+z0AKpflCnYQafq0V73ofzuw4KovpJWMk/WPs5oSHhuV4TZ8nRkF6BR4y rEvs1kq8Y6DuNqQGwY3yilpnmqfMzzlWo7MlY657domU54bhGOsvNuZZsFDlcBczQo6h9OKq ckkVHUMAw38pX+EghzEfhYVWYmLNv5G9TA/M2s3frO3aN7ukNDq7CKIwfVz71/VfPaLQMY7/ jirzp9yIBZEi4E+PwP38FAGiD+nxzuUJv1rvxf6koqUGoHRvdppju2JLrC2nKW0La7RX7uZJ esCVkamT/XaXPROBTrZZqwbIXh2uSMzgXkC2mE1dsBf2rdsJ4y73+0DYq7YE52OV9MNoCYLH vpkapmD00svsP4sskRsrquPHkBBVCJa22lTaS8Oow9hGQe7BDjEhsVoPol889F0mbTRb3klv mGQ6/B/HA0pGWR9wISY8a7D40/qz6eE6+Yg22mtN1T8FFlNbyVmtBj0R/2HfJYhGBElLPefH jhF0TA==
Message-ID: <0f89ddf1-4f26-b025-b769-415b74f91b94@riseup.net>
Date: Mon, 18 Jun 2018 23:29:00 +0000
MIME-Version: 1.0
In-Reply-To: <BYAPR19MB22487DA7854991C84B66B47A94710@BYAPR19MB2248.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/v5tOf2Q8Q4TtJOV7Msde9kMv_yY>
Subject: [Doh] some privacy ponderings wrt HTTPs and plain DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jun 2018 23:29:45 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

> I don't think we should not make it default, because most people need
> these things. We shouldn't include these in the standard either,
> since it is purely implementation dependent.
> 
> You may want to disable these features for your own preference. And
> you may develop, use, or recommend a client software that has options
> to disable these features.
 

Defining the user-agent in the specification is a direct possibility 
to avoid additional metadata/identifier that is not there in current DNS
and _not_ needed to fulfill the protocol goals. 

By saying "ok those that want to have privacy can set the agent to 'DoH client'"
will reduce the anonymity set and therefore the privacy of users.
(In fact if you are the only one setting it to 'DoH client' it is worse than 
doing nothing.)

DNS did pretty well without an user agent until now, lets ot add one
now in a protocol that aims to enhance privacy.

If MUST is not feasible, lets have at least a SHOULD for a static user agent string
to encourage a privacy-by-default setting (opt-out, not opt-in).

Specifying the user agent string in the draft will increase the likelihood that multiple
implementations will look the same at *some* level for the DoH server,
which increases the anonymity set and therefore the user's privacy.

>> * Set their Agent to 'DoH client', no matter what browser/library
> 
> Usually we need to include the software versions, mainly because
> older software may contain bugs, we need to take special care of
> them. 

I agree that data like user-agent strings is helpful for debugging
and to implement server-side workarounds for client-side bugs or error handling but 
the privacy of users - in a protocol that's primary goal is to provide 
privacy for end users - should be more important than ease-of-debugging
for us operators of DoH servers.

>> * Do not pass non-essential HTTP headers (like language)
> 
> For browsers, we usually cannot control it through XHR API.
> 
> For standalone clients, nobody would send extra headers since that
> requires extra code.

I'd suggest to add the recommendation to send minimal headers 
even if it might be obvious to some.

>> * Do not allow the DoH server to set cookies
> 
> Do you know RFC7873? Yes, there is already a Cookie system for
> traditional DNS protocol. And many public DNS services are already
> using it to protect against DDoS attack.
> 
> Additionally, since DoH protocol usually relies on Keep-Alive
> connections (otherwise it would be painfully slow), a single
> connection usually correspond to a single user or a single group of
> users, isn't it?

That will not be the case for all DoH clients.

I guess there is no expectation of unlinkability within multiple
DNS queries going over a single TCP connection. The concern
with cookies is more about linking multiple TCP connections
based on the cookie.


>> * Ponder TLS sessions resumption data settings
> 
> I am not familiar with this protocol. I guess disabling it will make
> connections much slower? (200x CPU time according to CloudFlare
> blog.)
> 
> Anyhow either enabling or disabling it does not affect security,
> because again, DoH usually relies on Keep-Alive connections and the
> user's IP can be tracked.

Not all DoH clients will use a single connection to maintain unlinkability properties
between some queries.
The IP address might not be a meaningful identifier if you do DoH over Tor
or it might not be available at all for DoH servers accessed via onion services.
https://blog.cloudflare.com/welcome-hidden-resolver/


> Extra A: Keep-Alive and Tor
> 
> I just talked about Keep-Alive. Since DoH runs over HTTP/2,
> Keep-Alive is normally enabled. If you are worried about it, you can
> run a non-standard DoH client with HTTP/1.0 over HTTPS. Please be
> warned that this is non-standard

The current draft RECOMMENDS HTTP/2 but does not require it, or
did I overlook the HTTP/2 requirement elsewhere?

"HTTP/2 [RFC7540] is the minimum RECOMMENDED version of HTTP for use
with DoH"



- -- 
https://mastodon.social/@nusenu
twitter: @nusenu_
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEElpDPH7u0KYWVTfK7rWE4wkXNQn4FAlsoQFoACgkQrWE4wkXN
Qn4K3w//WXsUMviGlqtt/B5PxSY8G6+UftUAdz8049X+nzBCG08VZG2utig1clao
ODoWCPfI159HYjOy8ad+nn58zetzVlKFDhbxyZ/UxpjyJMs92pXrjzGQ9gjapQzh
/XD29eF8o1t2i1N9fSbvZKWYS4/9skqrootUd40jcDPs0FVL7aXTZI6pHjxP21g9
ZLDUbbGaTwuFf5Gw6g2xBl3Z3Sm2XK4SHZFLPFnl4otynvRIo6ty9txe1+/zSULp
lwEjqIRW4rSSlUY4VPsNR8luOp6ojlWFM9EXyvQ8rinbAJEB66Yv0Mp+wT7lKnrM
vfeb3O5waKQMTJhydCm+KvDtk+NRRMa0uFMgSPOlNjcELPCpma9fpKFpkEW2jksz
Nl21t2itf/r3iG8au4xBbkozadYMghNoEENjFM0NZ56IZxbIye7ASInuCCcMmEOe
aciTg/rU512hRNx0lNddJOo2xCLw3qRFtm24qKx3zFhpTS2tKwt5gdJiPY05WC2R
hxXdx9dPiV4eu7dLW8JxGu2lkaSDHf+BVLNpko5f6cnlD7U1HSS0FjEBe1RwlBFk
sjeO2mD8yiE1Rl7hArmhAKVbMYYC7JzJ/IDPqEjVwgzY8RFbz0F4KzaLwS0lcz7v
K0QJLUw+2O5mG6P20G8CGs2ZuWfyqcdEj6Kq3cEfysfcGALntlI=
=sYdo
-----END PGP SIGNATURE-----