IETF Logo Mail Archive

Re: [dns-privacy] AD review of draft-ietf-dprive-dnsoquic

Sara Dickinson <sara@sinodun.com> Fri, 07 January 2022 11:56 UTC

Return-Path: <sara@sinodun.com>
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 6EE663A19D0 for <dns-privacy@ietfa.amsl.com>; Fri, 7 Jan 2022 03:56:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=sinodun.com
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 Ew0guPgJnVrO for <dns-privacy@ietfa.amsl.com>; Fri, 7 Jan 2022 03:55:57 -0800 (PST)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (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 B9B7C3A19CF for <dns-privacy@ietf.org>; Fri, 7 Jan 2022 03:55:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=90WMtmZZG2I+RajdVlMTZ8mhOXjtiFkdYCx1gsWtBlY=; b=CTVPDJS8Lcf6aOjX+x+6j0Kq5+ d6RA2vfOlu/oaSUxcy3/AvVtGnCCnE/ALdi/5W9qph0Lbb/KgX9p/w4t2DU1swnpY9dXR+Mw+dnly tSVVU0ajI01t2t6BqGR111Bx/Pm0EBLrBYl6kfoRnVeaqaNssV+rQYTNJPTZXjI3M8JAuYDHZfSH3 vMBzLgcg5DN6lN2yYEMZAfSS0MLcJPvRzViEWO/9Hu0PJbYjkZclRk324Q+8HJrA4ZFVUWS33nEg7 rvvds5h100DUGD09DX1F1Bglbl6KqbSM+TaN7on0VbB/zGvnvn/Y4/T40t0xS4aejHk0bF4I7DDjR 2zILL/oA==;
Received: from [62.3.64.153] (port=27008 helo=[192.168.12.101]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1n5nqX-0003Qy-Ch; Fri, 07 Jan 2022 11:55:53 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <B3FD48C7-4749-4F30-9D2F-8A693900C015@sinodun.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_535E7C3F-E026-4F59-90DC-C40A705315B1"; protocol="application/pgp-signature"; micalg="pgp-sha256"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
Date: Fri, 07 Jan 2022 11:55:45 +0000
In-Reply-To: <5AE859D2-64BA-43E0-99DB-B137D03D3FFF@cisco.com>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
References: <1B3BFBC8-89BC-4A30-88FE-4980E8BD3461@cisco.com> <8166E748-37F0-45EB-9353-6C1417B43FF5@cisco.com> <86C3E1C6-3374-4D99-B0E8-AB6FC74A1889@sinodun.com> <5AE859D2-64BA-43E0-99DB-B137D03D3FFF@cisco.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-BlackCat-Spam-Score: -16
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/aQrGCLNvCLi9hT77hzeK0rskYKM>
Subject: Re: [dns-privacy] AD review of draft-ietf-dprive-dnsoquic
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: Fri, 07 Jan 2022 11:56:03 -0000

> On 7 Jan 2022, at 07:38, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote:
> 
> Hi Sara
> 
> Thank you for your reply and the PRs.
> 
> Some more comments below, look for EV>

<snip>

>> 
>>  Section 6.4: same comment as above and also in other places.
> 
>    6.4 is proposed to change to a MUST for the use of padding in PR https://github.com/huitema/dnsoquic/pull/132. The main reason I can see for not using a QUIC padding API if it existed would be code complexity e.g. the implementation may choose to re-use padding logic already implemented in the DNS layer for DoT/DoH. I can add text about this if you think it is useful?
> 
> EV> adding some text about this would be helpful IMHO but not mandatory

Fair enough - text added in PR https://github.com/huitema/dnsoquic/pull/132/files

<snip>

> 
>>  Also in " it performs well compared" does it mean "better" or "similar" ?
> 
>    Adguard haven’t published exact data yet but did say in a presentation  “it seems that…. it does provide advantage over DoH in cellular data networks, as expected” and their user feedback "ranges from very positive to neutral”.  I’m reluctant to declare it ‘better’ without more raw data….
> 
> EV> in this case "better" would be wrong indeed but doesn't "well" imply 'good' ? I.e., "similar" could be better ? On this one, you are the native English speaker so I let you decide ;-)

I’ve switched to ‘similarly (and possibly better)’ to reflect the qualitative nature of Adguards findings.  (I also just noticed this is in the ‘Implementation Status’ section which will be removed anyway…)

Regards

Sara.

v2.23.0 | Report a Bug | By Email