Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...

Christian Huitema <> Sat, 10 October 2020 01:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 794133A16D7 for <>; Fri, 9 Oct 2020 18:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GD6Ncyxvlmt5 for <>; Fri, 9 Oct 2020 18:28:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 808B23A16D9 for <>; Fri, 9 Oct 2020 18:28:29 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1kR3gL-0003L0-L1 for; Sat, 10 Oct 2020 03:28:26 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 4C7S4f2D6Pz1PS5 for <>; Fri, 9 Oct 2020 18:28:18 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1kR3gI-0005T7-6g for; Fri, 09 Oct 2020 18:28:18 -0700
Received: (qmail 14444 invoked from network); 10 Oct 2020 01:28:17 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 10 Oct 2020 01:28:17 -0000
To: Tommy Pauly <>, Andrew Campling <>
Cc: Eric Orth <>, "" <>, James <>, "Vinny Parla (vparla)" <>
References: <> <> <> <> <LO2P265MB0573F65FD0DC18B528FD3282C20B0@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <CWXP265MB056674BB1E637A04AE2E8860C2080@CWXP265MB0566.GBRP265.PROD.OUTLOOK.COM> <>
From: Christian Huitema <>
Autocrypt:; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <>
Date: Fri, 9 Oct 2020 18:28:16 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------EA39566CAD9B0F19A06EB499"
Content-Language: en-US
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.05)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVHLLCAUZQwSYc YG9xRg07tETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwPzgJ2Ucltmld9WkfaJBY9Xt FNSzkMWnDricnMrpFJqSbcGVFX/FGbuOHQK9XwoDQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuEBv13SzGszAabFDmPEaULHg7GrRD93GuKsil0DsNlfaStdanO U07Z4oQbhfKrYy0P2DgAp0at4W1lubqSgAR5nJ0cRw78AMyqgpaL1PdpEt4pk7cjbWy91pm/jG4G U42zKLTFpngmCzMfOMV6XuhaobdAzbZabvf4+eAvvSn0D5YsJPkCw5CFSIcclHhCFNsjBr4UQT5O ZMr/oeXfpj/bf7wqyT5p50x81ZKcmzCu2U2eiziRmrRLaxpyV/vMvHCOFZjOuSCynj8XKyBvZw9X ghjgXQ1cH0qbjA5HkG/mj+A7/hwjNvmMkS9BXTs5dO3GKP9pWZyqSwiZS/khPlqY4hqZR3KVQgqF /fPYYAfEfsi2o9ASLxHXbQ+jSBvE2Hc2Ofx0ipX7i3565+nOd2lb+p5zTUAryLYvu33hLGL9FDoC DCBjJ6UStSJ4TwM1RQHBGyMuCIQcOZ9BSBS1VhPKkIDOcg83LXH4GksgCfTIQ57WXGH5SDG2kyRs dcYPy9Sti/KNE9X/EfsGUeyYJQ2POycAnpQIMSNxxOCOU1F642bb//sZQfBX6rDllW1IDUEeiISG XKr1myE5VVWYvdY4A2bjO41FyBEqIaDudcVplPF33DZy2XerWTbpLOxU1m0/dF21V+ep78H1f0wC 2O154dn2uWfCTMr7dqLRWHiVeRBJeOaBZ3QGltM4cLXJcDSyE4kswb7YzKhySm3KCdywFmvDK3PK rieG7T6bf9hS7hQx0S1sh0LPt0VUPewpiDOvFiQeKRnvGKxB4wV2/L1ZF2Hf4ys44rg2B8/9FmK9 a1Nwex3yoyNXmDWGgOLq9vyL
Archived-At: <>
Subject: Re: [dns-privacy] DNS and QUIC,HTTP/3 Long term vision...
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 10 Oct 2020 01:28:32 -0000

On 10/9/2020 3:32 PM, Tommy Pauly wrote:

> Hi Andrew,
> At least the cookie aspect of this isn’t just a “best practice” of one
> implementer, but something indeed built into the protocol spec
> (
>    Determining whether or not a DoH implementation requires HTTP cookie
>    [RFC6265 <>] support is particularly important because HTTP cookies are
>    the primary state tracking mechanism in HTTP.  HTTP cookies SHOULD
>    NOT be accepted by DOH clients unless they are explicitly required by
>    a use case.
> I think it is incorrect to characterize that DoH has a flawed design
> by basing itself on a protocol that allows cookies, or allows
> multiplexing. These are certainly tools provided by HTTP, but it is up
> to use them or not as appropriate. “Bad” implementations can put
> information in just about any protocol that could be used for tracking
> users.

I am not sure about that. These days, if a protocol design allow it to
be used for surveillance, you can be pretty sure that it will be.

Maybe DoH should add a requirement for servers to reject requests on
multiplexed connections, or reject requests that come with cookies
attached. That would provide a strong incentive for clients to do the
right thing.

> DoH has many benefits to the user for privacy and performance, and I
> consider it to be entirely in the spirit of RFC 8890.

OTOH, if an implementation (like Chrome) is going to use a dedicated
connection for DoH (H2 or H3), then it probably could just as well use
DoT or DoQ. The only issue is firewalls that would filter based on the
DoT or DoQ ALPN, but ECH/ESNI would easily fix that. Hard to believe
that this would not get better performance.

-- Christian Huitema