Re: [dns-privacy] [Add] avoiding unnecessary metadata in applications doing DNS / DoH

"Georgios Kontaxis" <georgios+ietf@99rst.org> Fri, 12 April 2019 01:51 UTC

Return-Path: <georgios+ietf@99rst.org>
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 B85A8120365 for <dns-privacy@ietfa.amsl.com>; Thu, 11 Apr 2019 18:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=99rst.org
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 t0M7RExbTPQi for <dns-privacy@ietfa.amsl.com>; Thu, 11 Apr 2019 18:51:55 -0700 (PDT)
Received: from mx.99rst.org (mx.99rst.org [52.22.122.190]) (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 0926312035E for <dns-privacy@ietf.org>; Thu, 11 Apr 2019 18:51:53 -0700 (PDT)
Received: from mail.kodaksys.org (localhost [127.0.0.1]) by mx.99rst.org (Postfix) with ESMTP id 02E6C5B0BD; Fri, 12 Apr 2019 01:51:53 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=99rst.org; s=20161001; t=1555033913; bh=UJSEijcOGTJVWYo9A8CWsx85GprjSwNAfxVCeJ246FE=; h=In-Reply-To:References:Date:Subject:From:To:Cc:From; b=z4tTzUnfuapxjq99zOKrZw+b05lb455RRslscVMljQrjGlylVLxBt43ZkZ9LBq05Z tGFWcPQNOfrIk/qF+zrgDxtgxsnby6cMtB1Iq0v+U75JAtqMJ1zT89HiWPrluDpR5G M94cfgW8aOMTbkm9cM7K9Izx+q9qKIBFJqycBPPl/DdW+z0RkJpn+0vmSCY8oCGsix 7ns9KGft4kezofu19ObYDe5ncp3z7sgLUHo8CnfLvfQWTluWOBposDi3mdVmwfNfl9 rYQ50UmOBTwVrj3b50HYRN0vS1JwZVOoqPCNuTMorFKCGbetdS4K4dyp9TEw5k9aOO fh7w8SdhsoKKQ==
Received: from 10.0.236.138 (SquirrelMail authenticated user georgios@kontaxis.org) by mail.kodaksys.org with HTTP; Fri, 12 Apr 2019 01:51:53 -0000
Message-ID: <5f45b4654309e500bde5991c79165b0f.squirrel@mail.kodaksys.org>
In-Reply-To: <CAHbrMsCqTFW5JPOUG40wyscwp-kQ06zBj9ef3p-wAQMAiKUmOQ@mail.gmail.com>
References: <fa5035a2-4a7c-ba7b-3835-e6c530c9970b@riseup.net> <CAHbrMsCqTFW5JPOUG40wyscwp-kQ06zBj9ef3p-wAQMAiKUmOQ@mail.gmail.com>
Date: Fri, 12 Apr 2019 01:51:53 -0000
From: Georgios Kontaxis <georgios+ietf@99rst.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: nusenu <nusenu-lists@riseup.net>, dns-privacy@ietf.org
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/NcRXc9rZFQLiv3FyW9L-lvbTqBE>
Subject: Re: [dns-privacy] [Add] avoiding unnecessary metadata in applications doing DNS / 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: Fri, 12 Apr 2019 01:51:57 -0000

> Moving thread from ADD to DPRIVE.
>
> I would suggest reaching out to the authors of
> https://tools.ietf.org/html/draft-dickinson-doh-dohpe-00 if you're
> interested in advancing that line of work.
>
> One major challenge related to User-Agent is forming a workable threat
> model.  It seems likely that an interested server could easily identify
> distinct user agents, even without this header field.  For example, the
Laperdrix et al. showed that the User-Agent field carries a non-trivial
amount of entropy, especially on mobile devices.

Pierre Laperdrix, Walter Rudametkin, Benoit Baudry. Beauty and the Beast:
Diverting modern web browsers to build unique browser fingerprints. 37th
IEEE Symposium on Security and Privacy. May 2016, San Jose, United States.

> TLS
> fingerprint alone is sufficient to uniquely identify most TLS
> implementations[1], and different HTTP/2 implementations produce different

Figure 5 in the TLS fingerprint study[1] shows that 99.9% of the
connections share 3,000 fingerprints and that 50% of connections share
just 10 fingerprints.

TLS fingerprints are certainly a source of entropy, however they appear to
be less identifying than the User-Agent field.

So if we force curious servers to stop relying on HTTP headers and use TLS
fingerprints instead then devices will become more difficult to track and
I think that will be an improvement.

> framing patterns.  Active probing (e.g. returning slightly invalid
> responses and observing how the client reacts) would likely allow the
> server to identify the client software completely.
>
> It's harder to motivate this kind of protection if it only works against
> "friendly" servers, especially because the User-Agent is extremely useful
> for server operations, capacity planning, etc.
>
DNS servers today don't get that information from clients.

Instead of trying to justify the removal of HTTP header fields we should
ask for evidence in support of any additional header fields beyond the
mandatory ones.

The DoH request examples in RFC 8484 appear to demonstrate the minimum
necessary set of HTTP headers.

> The DOHPE draft also contains several other suggestions (e.g. removing
> locale and language preference information) that may be easier to justify.
>
> [1] https://tlsfingerprint.io/
>
> On Thu, Apr 11, 2019 at 3:12 PM nusenu <nusenu-lists@riseup.net> wrote:
>
>>
>> DNS never had something like a user-agent field and that is fine,
>> but since browsers send one by default during their (non-DoH) operations
>> it is likely that they and other DoH clients will send the user-agent
>> along with their DoH queries.
>>
>> This exposes unnecessary metadata to the resolver, something that
>> didn't exist on the resolver before DoH.
>>
>> Since RFC8484 does not require user-agent headers
>> applications implementing DoH should not include
>> such metadata by default.
>> Some DoH implementations do it currently but it is early
>> enough to improve that.
>>
>>
>> DoH Privacy Enhancement: Do not set the user-agent header for DoH
>> requests
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1543201
>>
>>
>>
>> --
>> https://twitter.com/nusenu_
>> https://mastodon.social/@nusenu
>>
>> --
>> Add mailing list
>> Add@ietf.org
>> https://www.ietf.org/mailman/listinfo/add
>>
> _______________________________________________
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>