[DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis

"Hollenbeck, Scott" <shollenbeck@verisign.com> Tue, 31 March 2020 13:35 UTC

Return-Path: <shollenbeck@verisign.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E3E3A2110 for <dnsop@ietfa.amsl.com>; Tue, 31 Mar 2020 06:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 PAXIpdoHtPka for <dnsop@ietfa.amsl.com>; Tue, 31 Mar 2020 06:35:14 -0700 (PDT)
Received: from mail4.verisign.com (mail4.verisign.com [69.58.187.30]) (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 B0F843A210F for <dnsop@ietf.org>; Tue, 31 Mar 2020 06:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=2226; q=dns/txt; s=VRSN; t=1585661715; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=AIVIID9+teKyT1jxDMZcHRmvlkjPhej+86MQ+FTsEYQ=; b=Ucvinu+ikk6/yHKFKM8lR/fwpgM5xYKNnPgCRrUONtb8bclXWDMe4eMs Rk9EBJ64d6Y44S576HUFNxrbvn1J9Oqg2El1QcDxZSuCHqB5FKJpQ7BaF Ant/fykfcMUpjfzjFgIA8lSQ5ceSlWDRzT2QMV4RVYzpN0BHhWpzcjAWi zDI+oQIf84MoR7CNuqE5clOirjC/EVE2ALnQ5ecg8UmcKrTR2cLbqJt6D tv9phNbCbNhJd9sX34BTyV6Dw662iLNJUOovgdOXvl3aZNGC7PlqenQq/ ZnHVtEiV64k1+WMJ4t6IW2CMJvzqehRQUZg4u237wr/tnPLH3300OGze0 A==;
IronPort-SDR: iQzZjoLavtIGrFaEg+zkLxcYFoBgNNoiXDeVAMSUnECJOp3Je11QCbascfF2pO7khXQKbGdwMG xDgSevz7+6J0K0fE1M+hYc5beMKVUL/g03sj6CLiNniKdK3hSdSaDc10VSG2KnW34bKaQYY21Q UYbwdEmT3VG80GMCcN3ZirSA6nN78hC3nlwM/iJ8044MvaRm3fvXPr90xwnS5GjrFOFYnVNE15 ozsFTcsUne8gsrhIB5LVQm4is7sqE8tcecqqaXueAmHgB98ijcTyJPPR3IkGAu/rMO0/vBfr4i yTo=
X-IronPort-AV: E=Sophos;i="5.72,327,1580792400"; d="scan'208";a="1003385"
IronPort-PHdr: 9a23:Q6dBDBeS5UeSc/eYKFAXYCAAlGMj4u6mDksu8pMizoh2WeGdxcW6Zh7h7PlgxGXEQZ/co6odzbaP7ua4ASdbud7B6ClELMUQEUddyI0/pE8JPo2sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7MhdpdKyuQtaBx8u42Pqv9JLNfg5GmCSyYa9oLBWxsA7dqtQajZFtJ6osyhbFuGdEd/hZyW5mOV6YghLw6tut8JJ5/Clcpv0s+9RcXanmeqgzUKBVAikhP20p68LnsgXOQxGS7XUGSGUWlRRIAwnB7B7kW5r6rzX3uOlg1iSEJMP6Vb87Vyis4KdtUx/olTwINyUl/2HNi8x/l7xUrRS8rBFi2YHUYYWVNP1jfqPBeN4RWGRMUtpNWyFHH4ixaZYEAegcMuZCt4Tzp0UAowaiBQeiB+3vyyNHiHD50qAhz+QhCAPG0BA8E94SrnjZqsj+OqcIUeCyyanF1TvPYfFR2Tf57IjHbBYhruqSUr1scsrd0VQkGR7ZgVWXtYzlIz2Z3fkKvmiA7+pgUuavi2o5pAF3uTeg2NsjiorSi4IL1F/E7yR5wJ00Jd23Tk53e8KrEJxVtyyDMYZ9X8AsQ3lwtSon1rEKo4O3cSoExZg92hLSa/KKf5KH7x/gTOqdPCt0iGh4dL+9mxq+61Wsx+L/W8WuzVpHrTJJktfSuX0OyxDe782KR/lh8Uu9wzmC0h3f5f1YLk0xlafUNoAuwrA1m5cXrEvMAzH5lUPrh6GMbEok4PKn6+H/b7XjoZ+TKpF7hxnlMqQrhsy/GeM4MhUSX2SD+eSzyrnj/UrhTbhXkvM4irTVv5DCK8oUp6G1HxJZ3pw96xmjCDemyswYkWMdI11YYh6HkZLpO0rIIPziEfi/hFGsnC9qx/DAILLhHo3AImXfnLv7YLpw6UBRxBAuwd1f6Z9YEL4MLfHrVk/0rtPYDxs5MwKuw+bgDdVwzpgeWWKIAq+dNKPdr1mI6fkxLOaQZ48Yoyj9JOY/5/7vln85mFAdfa+z0ZQLb3C4G+xqI1+Fbnr0ntcBDWAKsxIjQ+zsk12CViZTam2zX60i+jE7BpiqDYDZRoCi0/S923LxEptNYXhuC12QHzHvbYrOE6MAbjmVOudgnyAKE7+7RNly+wupsVqw671jKufS8CATttar79Ny+/GZ3UUp9TtwC8mb2WyGTElqk3kJXD452uZ0pkkrmQTL6rRxn/ENTY8b3PhOSApvbZM=
X-IPAS-Result: A2EBBQA0RoNe/zCZrQpmhDmCWLBnCgEBAQEBAQEBAQcBExwEAQGHHzgTAgMBAQsBAQEFAQEBAQEFAwEBAQKGQAuCOyKEKVEBPkImAQQbDAW1RYVLhQGBOIxLgUI+gRGICIYIBI12iSSCNpYmdwMHgj2XDyWbbo8bnAUCBAIEBQIVgWmBe3BQgm1PGA2cZY5xMV8BAQ
Received: from BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 31 Mar 2020 09:34:50 -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.1913.005; Tue, 31 Mar 2020 09:34:50 -0400
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis
Thread-Index: AdYHX/gsc8iq0mP+SZ6sVAg3JqLxBQ==
Date: Tue, 31 Mar 2020 13:34:50 +0000
Message-ID: <51d9f36f70b84586a347a64088d7da4e@verisign.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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZScX4a9MEfaBmRdqEW07uHFhzZI>
Subject: [DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 13:35:17 -0000

I originally sent this to the list last July. Olafur provided some feedback (which has been incorporated into the text suggested below), but it seems to have slipped past the document editors. Trying again since the document has been revived after it recently expired...

I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to propose some additional text for the Security Considerations section in the spirit of this sentence from the abstract:

"Future versions of this draft will contain descriptions of different minimisation implementation choices that have been made since the RFC 7816 first came out, as well as deployment experience."

QNAME minimization has the consequence of reduction in the amount of information seen by authoritative name server operators. Active consideration of that consequence is worth capturing as a factor to be weighed when making the choice to implement QNAME minimization. Here's suggested text:

"In addition to the performance considerations described in Section 4, there's also a security consideration associated with the reduction of  data sent to parental name servers: they lose some of their ability to assess security threats.  This ability  has proven to be useful in, for example, studies of name collision vulnerabilities.  It was also instrumental in the research that led to the discovery of the JASBUG vulnerability. The reduction will also have an impact on the level of detail available for research studies such as DNS-OARC's annual Day in the Life of the Internet (DITL) data collection exercise.

For this reason, operators should consider the potential impact on threat analysis and research when reducing the level of detail included in queries to parental name servers. Without such consideration, a collection of individual decisions to reduce query information, over time, may well have the unintended consequence of "deciding" to no longer support threat analysis and research that the operational DNS community has historically relied on.  Alternative mechanisms for facilitating threat analysis and research are beyond the scope of this document."

Scott