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

Sara Dickinson <sara@sinodun.com> Fri, 23 August 2019 16: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 8E1411200F5 for <dns-privacy@ietfa.amsl.com>; Fri, 23 Aug 2019 09:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 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_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=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 onANFviCnoQ3 for <dns-privacy@ietfa.amsl.com>; Fri, 23 Aug 2019 09:56:45 -0700 (PDT)
Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [46.235.227.24]) (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 EE38E120020 for <dns-privacy@ietf.org>; Fri, 23 Aug 2019 09:56:44 -0700 (PDT)
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=E9YMK/6TLOy6RVcYV1NnhmFfEJ6ZA6c0p8BiZNlak+A=; b=lUuJxtfhEQgyccG/DU7j9b1R9T lsl/kuKH7YOa7daC6W/e+WkUPgGe0DGDQAFt/8dodXiCCDyZtWZ+ZcHAOc1KdkDBO+qTDhUQ+gaYN aHbh3qQRfqvHmk7GRwaLdctv2ec5gS05hvlLn6rXUmQ9imn8WXHCGJGM6nIX9+TnInHvFcnG0twPq aeizNyN5YqvW8ORNHEe2M3XccsCYFssDA1YMxv+L3P/dnZ99S0hDZBlZ2v7Lotyqm5wNGyj/0MGOs 3UJtoKxEY5hLBbasK041lsG+EL7N1Lydp6JkB8t3lhn7RgNGC1wAtZtX9g0EunFs32eAkQq88B89m 3JYE9wcg==;
Received: from [2001:b98:204:102:fffa::41e7] (port=50021) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <sara@sinodun.com>) id 1i1Cre-0001IY-9Q; Fri, 23 Aug 2019 17:56:42 +0100
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <52BD8FC7-A8E1-40A7-AD66-8D871A0345C9@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7B7B5EB2-138F-4376-A62D-6A7D88C5B687"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 23 Aug 2019 17:56:37 +0100
In-Reply-To: <c3736082a5b64aafbf00cb6f75f21470@verisign.com>
Cc: "vladimir.cunat+ietf@nic.cz" <vladimir.cunat+ietf@nic.cz>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>
References: <CADyWQ+EY14GdvEv7f0X6d=GNp6Kbdrkr6rNchszOgs_mf0zUXA@mail.gmail.com> <e43beb93-2c1d-13a2-38d1-f8b41cfb559e@nic.cz> <c3736082a5b64aafbf00cb6f75f21470@verisign.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/vTwblPxiy417hJ0-el8ulrIBDTc>
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 16:56:47 -0000


> On 21 Aug 2019, at 19:21, Hollenbeck, Scott <shollenbeck=40verisign.com@dmarc.ietf.org> wrote:
> 
>> -----Original Message-----
>> From: dns-privacy <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
>> 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?", 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 <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? 

> 
> 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…

Sara.