IETF Logo Mail Archive

Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.

David Schinazi <dschinazi@apple.com> Tue, 19 June 2018 01:30 UTC

Return-Path: <dschinazi@apple.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 38268131000 for <dnsop@ietfa.amsl.com>; Mon, 18 Jun 2018 18:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 tKjHtb1Hy389 for <dnsop@ietfa.amsl.com>; Mon, 18 Jun 2018 18:30:27 -0700 (PDT)
Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 B532B130E81 for <dnsop@ietf.org>; Mon, 18 Jun 2018 18:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1529371827; x=2393285427; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jqhgrki2bMgK1OHA4M8yAodtCPWVavv0Mi8FNiPu4pM=; b=pyjpYM2GIkmoZjcL+ApWltkNIbSii+Cfp/lih5sVpA9v+o4fOLVaeA+7WIdUr5C5 wtjJP1ZTYtzCISFnC882zGCUy4wtcGmu8W0NLaVumsmBrrUZl3a6Xlo8Tm2o8v2L Dc15r/C/Qx/rwkfVlY+TAyaBmi9JsVTwDS7Le8TueN8PDaeFh0aLbufu4xTr3Nfi 83nHgCDZNWZpUoh19vZdBAEUV+xga68M5lAovQ8z1Lt//UEFZA4eBWSyLsB+iP4z n5NKESie+YU2DpvZxdXfGB8C1T+W1oBTRusIAFJYTY7rqQOgRTV2sCQOJC7frHYN GVC/9bpIfjDEMy3u95qaHA==;
Received: from relay2.asia.apple.com (relay2.asia.apple.com [17.82.200.16]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 54.C0.15050.2BC582B5; Mon, 18 Jun 2018 18:30:27 -0700 (PDT)
X-AuditID: 11973e11-f0d049e000003aca-c9-5b285cb2aea9
Received: from echium.asia.apple.com ( [17.84.80.65]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by relay2.asia.apple.com (Apple Singapore relay) with SMTP id 27.72.30791.FAC582B5; Tue, 19 Jun 2018 09:30:23 +0800 (MYT)
Received: from [17.192.155.180] by echium.asia.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180403 64bit (built Apr 3 2018)) with ESMTPSA id <0PAJ00LKDQUIR340@echium.asia.apple.com>; Tue, 19 Jun 2018 09:30:22 +0800 (SGT)
Sender: dschinazi@apple.com
From: David Schinazi <dschinazi@apple.com>
Message-id: <A9DBE612-8260-45D6-9693-6ABA2628CE80@apple.com>
Content-type: multipart/alternative; boundary="Apple-Mail=_3961EC25-55C4-4F55-87D4-ABBC0038EC4C"
MIME-version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 18 Jun 2018 18:30:17 -0700
In-reply-to: <CAHw9_iKBiWe4-EgMkT6_rYHDS0QLjbaZ1BYAsg3XkF2368g+rg@mail.gmail.com>
Cc: Stuart Cheshire <cheshire@apple.com>, Michelle Cotton via RT <iana-questions@iana.org>, dnsop <dnsop@ietf.org>, IPv6 Operations <v6ops@ietf.org>
To: Warren Kumari <warren@kumari.net>, Mark Andrews <marka@isc.org>
References: <rt-4.2.9-2607-1515188710-296.989438-6-0@icann.org> <FAA35F1A-9AD4-4993-9A5C-53A6143B9DE7@isc.org> <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com> <DE670372-BF0E-4A81-8DB3-6CC2595B7D8E@isc.org> <CAHw9_iKBiWe4-EgMkT6_rYHDS0QLjbaZ1BYAsg3XkF2368g+rg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJLMWRmVeSWpSXmKPExsUiGHRCQHdzjEa0wbxzEhZ331xmsWhdvZTd 4sqL+ywWp4/tZbY4fOwykwOrR4+8x5IlP5k8Hjx+x+xx+8Yf9gCWKC6blNSczLLUIn27BK6M C0972Qp6tCvefqxrYPym0sXIySEhYCLRfmQFYxcjF4eQwBYmiSWHmxhhEj1TfzNBJOYzSXyY 9o8VwvnEKHFjxgZWkCphAWmJrgt3gWwODjYBLYkDa4xAwrwCNhLTGxpYQMLMAkkS1/riIcIm Erev/WCH6AyReHazH2wXi4CqxKzVV8BsToFgiaOvH7CDrGIWmMEo8f5zDzNIQkTAWWLhtRts EDfMZpKYcO8zC8SlShLTv98GS0gInGGTOPr7HdsERqFZCMtnIVkOYjMLaEssW/iaGaJER2Ly QkZUYQj74/kjTAsY2VYxCuUmZuboZuYZ6SUWFOSk6iXn525iBMXNdDvBHYzHV1kdYhTgYFTi 4dVYrx4txJpYVlyZe4hRmoNFSZxXV0wjWkggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPjVDs+ u3kThQzi48I/BTyLPpIaMv/a7/2aenN+3r55iWFa5HWDp3m3jjmfEffiyLu4OOR2SM1fGdYH msUGid9VTolpMWoXTdi+OXvWtz+3/updu5UyRW2Zv+rzfPtwpqmrtp4MnDst3dv+pVWGtnTX gqVvlv+u3pj4tefYK7Zz+s3xjf8bbnZvUGIpzkg01GIuKk4EAK1LZ4B8AgAA
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUiGBLgqLs+RiPa4PElAYtjd2os7r65zGLR unopu8WVF/dZLE4f28tscfjYZSYHNo+tJ3+wefTIeyxZ8pPJ48Hjd8wet2/8YQ9gjeKySUnN ySxLLdK3S+DKuPC0l62gR7vi7ce6BsZvKl2MnBwSAiYSPVN/M3UxcnEICcxnkvgw7R8rhPOJ UeLGjA2sIFXCAtISXRfuAtkcHGwCWhIH1hiBhHkFbCSmNzSwgISZBZIkrvXFQ4RNJG5f+8EO 0Rki8exmPyOIzSKgKjFr9RUwm1MgWOLo6wfsIKuYBWYwSrz/3MMMkhARcJZYeO0GG8QNs5kk Jtz7zAJxqZLE9O+32SYw8s9C2DcLyT4Qm1lAW2LZwtfMECU6EpMXMqIKQ9gfzx9hWsDItopR tCg1J7HSSC+xODNRL7GgICdVLzk/dxMjKAaCTgjsYJx1yOAQowAHoxIPr3m0RrQQa2JZcWXu IUYJDmYlEd7kX+rRQrwpiZVVqUX58UWlOanFhxilOViUxHktsmqjhATSE0tSs1NTC1KLYLJM HJxSDYxubffu1TtdW8auw3151fXsH+vt/kewu3sq7dZ59HrGbM1LpVaqz1417CuziGmLSHrV 9sVrntafb2//PblcdPi7b6da5Ibvz4V9b0/SOKJzON6cQ1GMadnHK5lOPpVvKgU3qaq4Fsdf nxMXcsg8jyO2+PvqmvfH9VpTQ26ER069kPM+5NLVBgclluKMREMt5qLiRADZpJUNfQIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/O-sPwmcwP7Jr0DIl6Hpw3q6uGjg>
Subject: Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
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, 19 Jun 2018 01:30:29 -0000

Hi, responses inline.

> On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews <marka@isc.org <mailto:marka@isc.org>> wrote:
> 
> This does not meet my requirements. There is zero need for any part of the normal DNS resolution
> process to know the IPV4ONLY.ARPA is special if IANA stopped signing the zone.

Could you take a look at draft-cheshire-sudn-ipv4only-dot-arpa please? It explains why some parts of the DNS resolution process do need to treat ipv4only.arpa as special, regardless of DNSSEC.

> On Jun 13, 2018, at 19:19, Warren Kumari <warren@kumari.net> wrote:
> 
> I read that a few times, and even when squinting I cannot figure out how that is supposed to work. Can someone enlighten me? I can see how a signed ipv4only.arpa allows a validating DNS64 server to validate the (well known!) v4 addresses, but the malicious AAAA RR detection bit confuses me...

I agree, there is no point in signing the A records for ipv4only.arpa since they are well-known, and for the same reason there is no point in checking it. So having A records signed or unsigned is irrelevant since no one should be querying for these A records anyway. Similarly, since the whole purpose of the AAAA records for ipv4only.arpa is to be overridden by a DNS64 recursive resolver which is not owned by .arpa, checking signatures will not validate anything useful.

I agree with Mark's point that queries will fail when the client is behind a validating resolver that has no special knowledge of ipv4only.arpa.

To resolve this, we'll update draft-cheshire-sudn-ipv4only-dot-arpa to mention that ipv4only.arpa MUST NOT be signed.

Thanks,
David

v2.23.0 | Report a Bug | By Email