Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
Antoine Germanos <antoine.germanos@hotmail.com> Mon, 30 October 2017 16:24 UTC
Return-Path: <antoine.germanos@hotmail.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 E84B61DA583 for <dns-privacy@ietfa.amsl.com>; Mon, 30 Oct 2017 09:24:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.924
X-Spam-Level:
X-Spam-Status: No, score=-3.924 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=hotmail.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 CtGE-vIKBcKd for <dns-privacy@ietfa.amsl.com>; Mon, 30 Oct 2017 09:24:10 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-oln040092068078.outbound.protection.outlook.com [40.92.68.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3129913FE80 for <dns-privacy@ietf.org>; Mon, 30 Oct 2017 09:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sUVxa2TbZqan1tdKmf6/lBDsppVMiHdRrVi0/aJSYEw=; b=CnpbCXIdNde3yIFQkHDJ8FmqH2tasL391IwdjJI+Ihs9ft2cTB7fIR72g7ncbUdxZ/77E3Ha4W0ddK5PNo4w5epTQ+OFVBbWHV15/VEgzY1PCVp8jD+zAIbe2MF/u+pydozZP/nA7MHVvW/dt0EUPOdinCkQrB9YoWvHfdZ5Ag6qD7qlXDvMSHBbx3802Vf/aSK0XqOvNftXDOPpIproK7EbpKOLg2T9qlOWdGSxkhUIWVKaNj43p1EmZeRg+uZHVkk7yLD6M2a+TikzdyoFUe0uRVoameNvBjqkur9ln9DaBJGbjC8GzcYLGmosVZl0ceRa8gP5g5SQtdr2qGOuVA==
Received: from AM5EUR02FT053.eop-EUR02.prod.protection.outlook.com (10.152.8.51) by AM5EUR02HT203.eop-EUR02.prod.protection.outlook.com (10.152.9.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5; Mon, 30 Oct 2017 16:13:32 +0000
Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com (10.152.8.59) by AM5EUR02FT053.mail.protection.outlook.com (10.152.9.196) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.178.5 via Frontend Transport; Mon, 30 Oct 2017 16:13:27 +0000
Received: from AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4]) by AM5PR0401MB2627.eurprd04.prod.outlook.com ([fe80::4079:74d1:d1c2:62b4%17]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 16:13:26 +0000
From: Antoine Germanos <antoine.germanos@hotmail.com>
To: "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Thread-Topic: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
Thread-Index: AQHTUZoEU0FdwrcpvU+0vMRD8u03Hg==
Date: Mon, 30 Oct 2017 16:13:26 +0000
Message-ID: <AM5PR0401MB2627AD2E6D8E45CB514F1DC399590@AM5PR0401MB2627.eurprd04.prod.outlook.com>
References: <mailman.2116.1509379854.4117.dns-privacy@ietf.org>
In-Reply-To: <mailman.2116.1509379854.4117.dns-privacy@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=hotmail.com;
x-incomingtopheadermarker: OriginalChecksum:D4272071531C40EA58179D62D628CDF190508B434A752A0424E5253F397C3730; UpperCasedChecksum:EDBA00652B4C52CA14C912650BEB610C5B74F132D2F71A23474C52C24FEF1F51; SizeAsReceived:7204; Count:46
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [QdhatbXGE0EOYz4Wt4d0KEsDG/cTxzIo]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM5EUR02HT203; 6:59kv+zMGwM7hEPt26F5SHonY5gWcJM4ofkwLrpO8or8G4/ZrKwPQ+vkWrlyXDNUMTa67zf579AV1Jlvuhlw+QKGnp5oG/kyROYsxXsz73/e9CUphVcCh/dqae6bBRjDuGO22zoQJwIygJiQmFf1iJlEYnpFMMk1iaODQvxxkLo4p0qr0s89vbKl2qhJ3aBp0V/9cqmyjaVgKCAuUJZITU/b8Yt2nfZstNaYtDJySAq2NrPpPwMq89iUNclACAQkL8+Cx7DNFNo0SjC0s5UtGk+5COQqVGZl0Hr6Oy9U7DZCh9xl53rEC4y7h1r8gxS5XZIf2foJH5W2nsNoTiyV8olDTrynVxYtpscUEaU0Me04=; 5:0Fn+1WC8zH2lmpPs44ZcfKJBcWaGdNcNdbjJQtE5NRi7TdGDoYvktmFEP+XZVo71VFmGR0jtzO1x0aciXB8WYUTDJqPrH02lO+eb7nz1OWvEEMt5jMH0yks0jXzwHkOvfj2aYLLZ1pM0L1ywHhs4mTKrEOn4HJQ3qkfI43h2e+0=; 24:XlTX4ZC4OrZJKZP4VnFiiYSE+fF4K7shDu5swiJ32B9Ouo13GEr5ZxjhhZnB7ZPTC4p+6i4Wq2KiOcvyfiyWXmBqT6VIPE4/JBPCDqRgSM8=; 7:jKZXoUWkNPwJTvxcRgCBILlNfUjyy5CxkgNjlf2fdy0YAjp6P0B2yRwZwPHMnFLprArUvefSyEuFUsRTK9H2usyVayAEioeU8lbQtuOnFTFO2pb51I1RT4rDxO9iYb5IhoH6G2EtMfTkEmFZblb15D/K9FBsXV+iEgbpZo3R5uUn+1g0L4Zv+vUPUzLf0JXpjMCIqhn10P9bAD3wPCZSuDDW0gPskZpovVxqka/u7h9dwKBHaLTSKTr3fA3qFPS0
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: 742cb7b9-1bc6-4fe1-92b1-08d51fb1272d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045); SRVR:AM5EUR02HT203;
x-ms-traffictypediagnostic: AM5EUR02HT203:
x-exchange-antispam-report-test: UriScan:(32856632585715)(158342451672863)(192374486261705)(81439100147899)(21532816269658);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:AM5EUR02HT203; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5EUR02HT203;
x-forefront-prvs: 0476D4AB88
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:AM5EUR02HT203; H:AM5PR0401MB2627.eurprd04.prod.outlook.com; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_AM5PR0401MB2627AD2E6D8E45CB514F1DC399590AM5PR0401MB2627_"
MIME-Version: 1.0
X-OriginatorOrg: hotmail.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 742cb7b9-1bc6-4fe1-92b1-08d51fb1272d
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 16:13:26.9295 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5EUR02HT203
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/MpLYNSpwHftFeuYAwB31rLyIlx0>
Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 30 Oct 2017 16:24:17 -0000
Antoine Germanos™ ________________________________ From: dns-privacy <dns-privacy-bounces@ietf.org> on behalf of dns-privacy-request@ietf.org <dns-privacy-request@ietf.org> Sent: Monday, October 30, 2017 6:10:54 PM To: dns-privacy@ietf.org Subject: dns-privacy Digest, Vol 44, Issue 13 Send dns-privacy mailing list submissions to dns-privacy@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/dns-privacy or, via email, send a message with subject or body 'help' to dns-privacy-request@ietf.org You can reach the person managing the list at dns-privacy-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dns-privacy digest..." Today's Topics: 1. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Stephane Bortzmeyer) 2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Paul Hoffman) 3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Daniel Kahn Gillmor) 4. Re: Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? (Daniel Kahn Gillmor) 5. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Paul Hoffman) 6. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement (Stephen Farrell) ---------------------------------------------------------------------- Message: 1 Date: Mon, 30 Oct 2017 14:34:03 +0100 From: Stephane Bortzmeyer <bortzmeyer@nic.fr> To: Daniel Kahn Gillmor <dkg@fifthhorseman.net> Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <20171030133403.2yyw4m4ldjdcyl7f@nic.fr> Content-Type: text/plain; charset=us-ascii On Fri, Oct 27, 2017 at 11:40:15PM -0400, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote a message of 219 lines which said: > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic > metaquery, I see the point but it seems to me a small detail in a 29-pages document. So, IMHO, it should not cause yet another long delay for a draft that already lingered too much. > But i think the other changes between draft-10 and draft-11 are > unwarranted and should be reverted. There are very few changes and, except the DNSSEC *requirment*, they seem good to me. I agree with Sara "I really do think a description there of the trade-offs of DNSSEC validation are warranted". ------------------------------ Message: 2 Date: Mon, 30 Oct 2017 07:46:43 -0700 From: "Paul Hoffman" <paul.hoffman@vpnc.org> To: "Sara Dickinson" <sara@sinodun.com> Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <9D3816E2-AE0D-4803-BBE8-FA98A196D376@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed On 30 Oct 2017, at 6:11, Sara Dickinson wrote: > I?d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. There are many ways to get a BOGUS response that have nothing to do with the information being "not legitimate". Typically today, BOGUS comes from misconfigured servers such as expired keys, some nameservers out of sync, and so on. You cannot infer from a BOGUS response about why it is bogus. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a ?normal? client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ?normal? ones. Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to me. > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. ...unless the attacker can spoof the (typically) two servers that the client has addresses to. > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn?t fail? If the WG decided that to be the case then it > needs to be clear in the document this choice comes with an additional > risk (and yet still not guarantee of privacy). It is only an "additional risk" for a very limited attacker who can only attack one of a set of addresses. If the WG wants to go down the path of making Opportunistic encryption even more difficult in order to feel that we offered the best security, requiring DNSSEC on the client is a good way to do that. I would still prefer more ubiquitous encryption. --Paul Hoffman ------------------------------ Message: 3 Date: Mon, 30 Oct 2017 16:08:35 +0100 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Sara Dickinson <sara@sinodun.com> Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <871slkd66k.fsf@fifthhorseman.net> Content-Type: text/plain; charset="utf-8" On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: > I really do think a description there of the trade-offs of DNSSEC > validation are warranted I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted. I just come to a different conclusion than the requirements in draft-11. > if it ends up just being a MAY (although I would like to see SHOULD as > a minimum for opportunistic). SHOULD validate, but with what failure mode? are we really saying that opportunistic SHOULD deliver a DoS instead of a loss of privacy? I discuss a few optional responses for failures in opportunistic mode below. > I can also recognise the implementation overhead, however this is > required for only one of the 3 cases of how the client may be > provisioned: > > * IP address only (no meta-query required) > > * IP address and ADN (no meta-query required) > > * ADN only (meta-query required) > > So it is for the case where a client was directly and securely > configured with just the ADN of a server it expects to provide > privacy. If a client doesn?t want to implement DNSSEC then it can > always restrict the opportunistic profile to requiring one of the > first 2 configurations. The cheapest and simplest implementation in terms of user experience to get to verifiable opportunistic profile (that is, a profile that can at least report that DNS privacy has been achieved, even if it won't be enforced) seems to be: * allow the local administrator to provide a name for the preferred DNS resolver Since it's opportunistic, it can even be enabled by default. But this is the "ADN only" use case. Saying it's not usable with the opportunistic profile without DNSSEC validation would be a shame. >> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for >> strict clients (no mitigation), > > Agreed - DNSSEC validation just provides earlier detection for Strict clients or, converts success to failure in the case of DNSSEC misconfiguration (because the connection would otherwise have succeeded) :( > I?d disagree that connecting to a server for which the meta-query > response failed DNSSEC validation results in _just_ a loss of privacy > for Opportunistic in this case. If the answer was BOGUS then it seems > reasonable to assume the server is not legitimate and so connecting > also results in the clients' entire DNS service being controlled by > the attacker. sure, but this is the case for non-private DNS as well, right? So the mitigation in this case is with respect to the features that "private DNS" is supposed to offer. Whatever those features are, they are absent given an attacker-controlled DNS resolver. So if the DNS-over-TLS server is intended to also provide integrity protection, yes, that would also be lost. I think we're agreeing here, right? I apologize if "loss of privacy" is a misleading shorthand. > Take the case where the DNS server from DHCP really is legitimate. The > fact that the meta-query answer _could_ be spoofed provides a vector > for an opportunistic client to be directed to an attackers' DNS > server. Note that this attack is not possible on a ?normal? client > that directly uses the DHCP provided server, the attacker has to > attack each individual query. My concern here is that without DNSSEC > validation of the re-direct Opportunistic clients have an additional > risk of this kind of attack than ?normal? ones. ok, i think i understand. The concern is that a non-network-controlling attacker who can spoof DNS responses but can't spoof DHCP responses can now take over full DNS resolution of opportunistic clients just by racing (and winning) the legitimate metaquery response. This is true, but the threat model we're worrying now include all of the following characteristics: * attacker does not control the client's network (otherwise, they could redirect the port 853 queries anyway) * attacker cannot (or has failed to) race the client's DHCP connection (otherwise, they'd point to a different DNS server anyway) * attacker *can* race the legitimate response to the client's opportunistic metaquery. * client is in opportunistic mode. So the question is, in this particular corner case, what is the right mitigation to the scenario where "if DNSSEC validation of the opportunistic metaquery fails?" ? if the answer is "?proceed as though it had not failed (trying to connect to the preferred server's proposed address), but continue listening for another response to the metaquery; prefer subsequent metaquery responses that do have DNSSEC validation over those responses that are not DNSSEC validated." Then i'd be ok with it, but it's not specified in the draft. If the answer is "?hard-fail and deny DNS service", then i think that's incorrect given the goals of opportunistic mode. If the answer is "?stop trying to use opportunistic DNS privacy entirely, but fall back to using the DHCP-provided resolver for all queries" then i think that's a mistake -- we've already demonstrated that we're in a scenario where the attacker can race the DHCP-provided resolver and win. So what do we gain by making this the failure mode? > Also this is only a guaranteed DoS for the case where there is only a > single server configured. If there are multiple servers then the > attacker must spoof the meta-query answers for _all_ the servers to > achieve DoS. If it only spoofs one then the client can still get > service. I think this equivalent to my responses-to-failed-validation #2 -- retrying the opportunistic metaquery. (also, equivalent to "?but continue listening?" in the paragraphs above.) I agree that's an interesting case, but i think it's an additional complexity as yet unspecified in the draft. :( > So one way to look at the trade-off seems to be is it worse that an > attacker can block your DNS service or gets an extra chance to control > all your DNS answers? I think you are arguing that for opportunistic > the latter is preferable because a principle of Opportunistic is that > it shouldn?t fail? If the WG decided that to be the case then it needs > to be clear in the document this choice comes with an additional risk > (and yet still not guarantee of privacy). it is "an extra chance only" in the scenario where points outlined above hold. An attacker who can also race and beat the DHCP server has the exact same chance already, right? > Technically his DISCUSS was on a different topic (SPKI handling) as > Stephane pointed out, this was an issue that came out of a separate > comment he made. Hm, sorry, i'll try to follow up on that in the other sub-thread. Thanks for the discussion. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/671db67b/attachment.asc> ------------------------------ Message: 4 Date: Mon, 30 Oct 2017 16:27:16 +0100 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net> To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, dns-privacy@ietf.org Subject: Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked? Message-ID: <87y3nsbqqz.fsf@fifthhorseman.net> Content-Type: text/plain; charset="us-ascii" On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have interop problems." I agree that this DISCUSS should be cleared, since draft-10 and draft-11 both state: A client MUST only indicate support for raw public keys if it has an SPKI pinset pre-configured (for interoperability reasons). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/639c412b/attachment.asc> ------------------------------ Message: 5 Date: Mon, 30 Oct 2017 08:42:18 -0700 From: "Paul Hoffman" <paul.hoffman@vpnc.org> To: "Daniel Kahn Gillmor" <dkg@fifthhorseman.net> Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <1B2537D5-DFD7-407A-A84E-925C85EF9268@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote: > On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote: >> if it ends up just being a MAY (although I would like to see SHOULD >> as >> a minimum for opportunistic). > > SHOULD validate, but with what failure mode? +1 to the question: we're talking about Opportunistic mode here. > are we really saying that > opportunistic SHOULD deliver a DoS instead of a loss of privacy? Some of us are most emphatically not saying that. . . . > sure, but this is the case for non-private DNS as well, right? So the > mitigation in this case is with respect to the features that "private > DNS" is supposed to offer. Whatever those features are, they are > absent > given an attacker-controlled DNS resolver. So if the DNS-over-TLS > server is intended to also provide integrity protection, yes, that > would > also be lost. I think we're agreeing here, right? I apologize if > "loss > of privacy" is a misleading shorthand. > >> Take the case where the DNS server from DHCP really is legitimate. >> The >> fact that the meta-query answer _could_ be spoofed provides a vector >> for an opportunistic client to be directed to an attackers' DNS >> server. Note that this attack is not possible on a ?normal? >> client >> that directly uses the DHCP provided server, the attacker has to >> attack each individual query. My concern here is that without DNSSEC >> validation of the re-direct Opportunistic clients have an additional >> risk of this kind of attack than ?normal? ones. > > ok, i think i understand. The concern is that a > non-network-controlling > attacker who can spoof DNS responses but can't spoof DHCP responses > can > now take over full DNS resolution of opportunistic clients just by > racing (and winning) the legitimate metaquery response. > > This is true, but the threat model we're worrying now include all of > the > following characteristics: > > * attacker does not control the client's network (otherwise, they > could > redirect the port 853 queries anyway) > > * attacker cannot (or has failed to) race the client's DHCP > connection > (otherwise, they'd point to a different DNS server anyway) > > * attacker *can* race the legitimate response to the client's > opportunistic metaquery. > > * client is in opportunistic mode. > > So the question is, in this particular corner case, what is the right > mitigation to the scenario where "if DNSSEC validation of the > opportunistic metaquery fails?" ? > > if the answer is "?proceed as though it had not failed (trying to > connect to the preferred server's proposed address), but continue > listening for another response to the metaquery; prefer subsequent > metaquery responses that do have DNSSEC validation over those > responses > that are not DNSSEC validated." Then i'd be ok with it, but it's not > specified in the draft. > > If the answer is "?hard-fail and deny DNS service", then i think > that's > incorrect given the goals of opportunistic mode. Agree. And fully agree that an attacker who can do the third bullet *but not the second* is a very obscure corner case. Having this document say, in essence, "you don't get opportunistic encryption unless you add a DNSSEC validation stack" feels like a regression to the original goals of this WG. --Paul Hoffman ------------------------------ Message: 6 Date: Mon, 30 Oct 2017 15:59:21 +0000 From: Stephen Farrell <stephen.farrell@cs.tcd.ie> To: Paul Hoffman <paul.hoffman@vpnc.org>, Daniel Kahn Gillmor <dkg@fifthhorseman.net> Cc: dns-privacy@ietf.org Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Message-ID: <ac8f15bf-73fb-6728-e846-293c4da5bfaa@cs.tcd.ie> Content-Type: text/plain; charset="utf-8" Hiya, On 30/10/17 15:42, Paul Hoffman wrote: > Having this document say, in essence, "you don't get opportunistic > encryption unless you add a DNSSEC validation stack" feels like a > regression to the original goals of this WG. I'm not sure that having a stack is such a barrier in reality. Requiring that some DNSSEC signatures validate in order to win the opportunistic game is the problem I think. I'd personally be fine with a "MUST try DNSSEC" statement, though that could be argued to be OTT, given the probability of success, but as DKG and you (and I) agree, it's the failure mode that needs fixing in the draft. S. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/00fb8f85/attachment.asc> ------------------------------ Subject: Digest Footer _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy ------------------------------ End of dns-privacy Digest, Vol 44, Issue 13 *******************************************
- [dns-privacy] review of draft-ietf-dprive-dtls-an… Daniel Kahn Gillmor
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Ben Schwartz
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Wouters
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Wouters
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Wouters
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Daniel Kahn Gillmor
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Stephen Farrell
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Sara Dickinson
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Stephane Bortzmeyer
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Hoffman
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Daniel Kahn Gillmor
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Hoffman
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Stephen Farrell
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Sara Dickinson
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Antoine Germanos
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Wouters
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Sara Dickinson
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Paul Hoffman
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Stephen Farrell
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Sara Dickinson
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Sara Dickinson
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Konda, Tirumaleswar Reddy
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Daniel Kahn Gillmor
- Re: [dns-privacy] review of draft-ietf-dprive-dtl… Antoine Germanos