Re: [Doh] some privacy ponderings wrt HTTPs and plain DNS

Petr Špaček <petr.spacek@nic.cz> Wed, 20 June 2018 08:38 UTC

Return-Path: <petr.spacek@nic.cz>
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 ED383130E55 for <doh@ietfa.amsl.com>; Wed, 20 Jun 2018 01:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.021
X-Spam-Level:
X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] 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 DLrBFyaybpqX for <doh@ietfa.amsl.com>; Wed, 20 Jun 2018 01:38:57 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C5730124BE5 for <doh@ietf.org>; Wed, 20 Jun 2018 01:38:56 -0700 (PDT)
Received: from [172.20.6.227] (unknown [172.20.6.227]) by mail.nic.cz (Postfix) with ESMTPSA id 0117360527 for <doh@ietf.org>; Wed, 20 Jun 2018 10:38:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1529483935; bh=jH5uYgzOUGlmM1XauveDLa7dYHQI2o6iP3e0NSqympI=; h=To:From:Date; b=DgMMwZDtU6Vhszf2QG+Bhyuh1XGebxU2iAQusK7xzj0h2LSIb4xQ4vAoe7ZIbjXKB KehQfewR0ZkJQBh3SYZ3tLv0qjSIsSJlrIX7+CRZJAsupznLVB2T5eXtz07ApNI9RN oKpU99ytd82Myq9GuK4qhBkuazXojuVycxae/zUY=
To: doh@ietf.org
References: <20180618112116.GB9195@server.ds9a.nl> <BYAPR19MB22487DA7854991C84B66B47A94710@BYAPR19MB2248.namprd19.prod.outlook.com>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <fec8b0cc-b2d4-2c9d-3dec-1779b25da2df@nic.cz>
Date: Wed, 20 Jun 2018 10:38:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <BYAPR19MB22487DA7854991C84B66B47A94710@BYAPR19MB2248.namprd19.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/2x1e0dKDD2O5aRPVOcmW-piV-hA>
Subject: Re: [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: Wed, 20 Jun 2018 08:38:59 -0000

On 18.6.2018 18:00, Star Brilliant wrote:
>> * 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.

It is very important to note that DNS cookies are, unlike HTTP cookies, 
designed to just verify IP addresses and nothing else.

I.e. an properly implemented DNS cookies will change once client's IP 
address changes so DNS cookies cannot be used to track client who is 
moving across different networks. This is very different property when 
compared to traditional HTTP cookies which easily facilitate tracking.

> 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?
> 
> Similar to RFC7873 Cookie, HTTP Cookie also serves as a tool to defend servers from DDoS attacks, and is already widely adapted by many leading CDN providers.
> 
> My suggestions is to give the user an option to disable Cookies, or limit Cookies to a very short lifetime (e.g. 2 minutes).

Wouldn't it cause all the DDoS mitigations work only for two minutes?

-- 
Petr Špaček  @  CZ.NIC