Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis

"Hollenbeck, Scott" <shollenbeck@verisign.com> Fri, 23 August 2019 17:45 UTC

Return-Path: <shollenbeck@verisign.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 5ECE01208C4 for <dns-privacy@ietfa.amsl.com>; Fri, 23 Aug 2019 10:45:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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=verisign.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 BaIKuIuqOBdk for <dns-privacy@ietfa.amsl.com>; Fri, 23 Aug 2019 10:45:34 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 6B6B2120884 for <dns-privacy@ietf.org>; Fri, 23 Aug 2019 10:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=13052; q=dns/txt; s=VRSN; t=1566582334; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=j5rAXJc4pUAYCh/9HSMP4yD5TVyO4XmJ6XBzzxKGxXQ=; b=d+LyvVsTG2EIqVVTKrG+VStwafEeMOz3fgVL1UpBQWEOOWlzIUzbgSUZ 6WNK/nTNOoA3yWp1GIzKBdhujhTiPhAuA46Ji+lRiJWc1e2037xZk6yVD nisigXNElWzqnAuvVs4UnoU2/H1l2dGcyKvmMagRp74ciKi6cVcFVY/0Z GrjUzF9SZjf8TKUbQlsBtClFkv8N66gpQGbF19TM1D7esga73CaBiKOxZ CUEpFRU5ozWd+5BbtxiroJ3E39ifUDz3QITiIV+b6HfdaGmHrCze+ebIe Qn8iRbMUrOEPzkLMG8K9ew/erqVK5JRf8Y0RcUSsdOzHLmNgxJkVg6ivj w==;
X-IronPort-AV: E=Sophos;i="5.64,422,1559520000"; d="scan'208,217";a="8396394"
IronPort-PHdr: =?us-ascii?q?9a23=3Algrc6xMBxcmXloDoz4Yl6mtUPXoX/o7sNwtQ0K?= =?us-ascii?q?IMzox0I/X8rarrMEGX3/hxlliBBdydt6sezbOK4+u5ADdIyK3CmUhKSIZLWR?= =?us-ascii?q?4BhJdetC0bK+nBN3fGKuX3ZTcxBsVIWQwt1Xi6NU9IBJS2PAWK8TW94jEIBx?= =?us-ascii?q?rwKxd+KPjrFY7OlcS30P2594HObwlSizexfK1+IA+roQjetcQajpZuJrs/xx?= =?us-ascii?q?DUvnZGZuNayH9yK1mOhRj8/MCw/JBi8yRUpf0s8tNLXLv5caolU7FWFSwqPG?= =?us-ascii?q?8p6sLlsxnDVhaP6WAHUmoKiBpIAhPK4w/8U5zsryb1rOt92C2dPc3rUbA5XC?= =?us-ascii?q?mp4ql3RBP0jioMKjg0+3zVhMNtlqJWuBKvqQJizY7Ibo+bN/R+caHcfdwGSm?= =?us-ascii?q?VMRdxeWzBDAo6mc4cDE+gMMOBFpIf9vVsOqh6+CBGiCO3tzT9Ignv20rM80+?= =?us-ascii?q?s6Dw7JwA8gE8oTu3rJsNr1M7sSUfy7wKLVyjjDdPNW2TD56IjMbB8hp+qDUq?= =?us-ascii?q?xsfsrS0kQvCR3Kjk+RqYz+PjOV2eINv3KH4OpnUOKikmgqoBxyrDi33sogl5?= =?us-ascii?q?XFipgIxl3G+yh12ps5KN22RUJhbtOpFINcuzyGO4dsX88vQX1ktDwnxrAJup?= =?us-ascii?q?O3ZjUGxZc/yx7RdfOKcJSE7xfmWeuTPTh0mGhqdbeiixmu7Uetz+3xWdSq31?= =?us-ascii?q?ZEqydIlsTDuW0T2BHV98OJUOFy/l271jaKzw3T7+ZELl0qmqfDMJ4hx6Iwlo?= =?us-ascii?q?IUsUTeAi/6gEX2g7GSdkUj4uWl9vjpbK37qpCcL4F6hQDxPrgwlsClH+Q3Lg?= =?us-ascii?q?8OX3KD+eimzrLs4Ff1QKtQjv0tlKnVqozVJcMepqKhAg9V1Jgs6wqnAju7zN?= =?us-ascii?q?gUh2QLIVBLdR6dkoTkO1/DLOr3APq7m1islS1kx/HCPr3vGJXNKX3Dna/6fb?= =?us-ascii?q?Z97E5czA4zws5Z551PFL4OPPHzV1TvtNPGFB85Mhe0w+foCNV7zI8RRWWPAq?= =?us-ascii?q?qBPKPIrVCI/v4vI/WLZIINozbyMeIl6OT1gH8imF8de66p0oYKaHC+BPhpP0?= =?us-ascii?q?KZYX/0iNcbDWgKphY+TPDtiFCaTz5TY2y9UL895jE+CYKmF53PSZywgLyHxi?= =?us-ascii?q?i7AppaZmFYBVCQH3flbIOEW/YQZy6IPsBgkyQOVaK9RI85yRGuqAj6xqJ6Ie?= =?us-ascii?q?rS4S0UrIrj1MJ05+3Njx496Tx1At+c026TU2F0kHkERzgs3KBw8gRBzQLJyq?= =?us-ascii?q?FiitRDFNpU6+5PFAw9MNSUm/dzEdnaQQPHeduUThCtRdDwUh8rSddkif8JZ0?= =?us-ascii?q?JwHd+vhROHlxGhBKMJ3fTfH5wz9qbR2XL8LMVV1Xvc1bIggF9gScxKYz71zp?= =?us-ascii?q?Vj/hTeUtaa236SkLynIPwR?=
X-IPAS-Result: =?us-ascii?q?A2FZAACbJWBd/zGZrQplGgEBAQEBAgEBAQEHAgEBAQGBZ?= =?us-ascii?q?4EWgW+BLwqEFo5TgkCaVDwJAQEBAQEBAQEBBwElCgEBAoQ9AheCdDgTAgoBA?= =?us-ascii?q?QEEAQEBAQEGAwEBAQKGFgELgjoiHE07MAEBAQEBAQEBAQEfAg0zMAEBAQEDH?= =?us-ascii?q?QYKHDAMBAIBCBEEAQEoAwICAjAUCQgCBA4FCIMbgR18rDaBMopZgTSEe4cNg?= =?us-ascii?q?UE+gRGDEj6CYQSBSS0fCIJNglgEjEiCUIURJJcaAwYCgh2GCWGEPokTI4Iyi?= =?us-ascii?q?0qKUo1nh2mQOQIEAgQFAhWBZ4F6cIM8CYJxgzqEWYV6cgGOC4EhAQE?=
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Fri, 23 Aug 2019 13:45:27 -0400
Received: from BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde]) by BRN1WNEX02.vcorp.ad.vrsn.com ([fe80::7c0a:1cc:5def:9dde%4]) with mapi id 15.01.1713.004; Fri, 23 Aug 2019 13:45:27 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "sara@sinodun.com" <sara@sinodun.com>
CC: "vladimir.cunat+ietf@nic.cz" <vladimir.cunat+ietf@nic.cz>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis
Thread-Index: AQHVVo3OAq2kVjP6pkGU3WoDIXzDGKcF7DwQgANRKoD//8mmQA==
Date: Fri, 23 Aug 2019 17:45:27 +0000
Message-ID: <3284930ac7f34bc9b98eb5aafed17303@verisign.com>
References: <CADyWQ+EY14GdvEv7f0X6d=GNp6Kbdrkr6rNchszOgs_mf0zUXA@mail.gmail.com> <e43beb93-2c1d-13a2-38d1-f8b41cfb559e@nic.cz> <c3736082a5b64aafbf00cb6f75f21470@verisign.com> <52BD8FC7-A8E1-40A7-AD66-8D871A0345C9@sinodun.com>
In-Reply-To: <52BD8FC7-A8E1-40A7-AD66-8D871A0345C9@sinodun.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_3284930ac7f34bc9b98eb5aafed17303verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/QDce3SkF9EVWTSWCfF4OV9ExFf4>
Subject: Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis
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, 23 Aug 2019 17:45:37 -0000

From: Sara Dickinson <sara@sinodun.com>;
Sent: Friday, August 23, 2019 12:57 PM
To: Hollenbeck, Scott <shollenbeck@verisign.com>;
Cc: vladimir.cunat+ietf@nic.cz; dns-privacy@ietf.org
Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-dprive-rfc7626-bis









   On 21 Aug 2019, at 19:21, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org<mailto:shollenbeck=40verisign.com@dmarc.ietf.org>> wrote:



      -----Original Message-----
      From: dns-privacy <dns-privacy-bounces@ietf.org<mailto:dns-privacy-bounces@ietf.org>> On Behalf Of Vladimír
      Cunát
      Sent: Monday, August 19, 2019 8:58 AM
      To: dns-privacy@ietf.org<mailto:dns-privacy@ietf.org>
      Subject: [EXTERNAL] Re: [dns-privacy] Working Group Last Call for draft-ietf-
      dprive-rfc7626-bis

      Hello,

      I now read through the whole document, and I see one thing that might be a
      little bit confusing - the beginning of page three reads like QNAME
      minimization is not possible or at least never done, and contrary to
      rfc7626 itself it isn't even mentioned in the whole document.  I would
      suggest to at least reduce the strength of the wording ("always"), and/or
      mention rfc7816.  I don't have much data at hand, but I believe that some
      reduction of QNAMEs isn't as exotic as it used to be.


   Agreed, and I'll suggest a sentence (enclosed by **) for the end of the third paragraph of the Introduction:

   "It is important, when analyzing the privacy issues, to remember that the question asked to all these name servers is always the original question, not a derived question.  The question sent to the root name servers is "What are the AAAA records for www.example.com<http://www.example.com>?";, not "What are the name servers of .com?".  By repeating the full question, instead of just the relevant part of the question to the next in line, the DNS provides more information than necessary to the name server. **In this simplified description, recursive resolvers do not implement QNAME minimization as described in RFC 7816 [RFC7816], which will only send the relevant part of the question to the upstream name server.**”



   Thanks very much for this text. I’m wondering about also referencing this study:

   https://labs.ripe.net/Members/wouter_de_vries/make-dns-a-bit-more-private-with-qname-minimisation

   which attempts to asses the deployment of QNAME minimisation to show it is actually being deployed in the wild?


   [SAH] That seems reasonable.


   It may be more desirable to reference 7816bis, but that would add an Internet-Draft reference dependency that folks might not want to add.



   Good point. I’d prefer to just reference RFC7816 unless anyone objects…



   [SAH] A reference to 7816 is reasonable assuming that there’s little risk of significant specification deviation between it and 7816bis. That’s probably a reasonable assumption.



   Scott