Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa's delegation should be insecure.
David Schinazi <dschinazi@apple.com> Wed, 13 June 2018 02:28 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 77316130DC2 for <dnsop@ietfa.amsl.com>; Tue, 12 Jun 2018 19:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level:
X-Spam-Status: No, score=-4.31 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] 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 KjOEAiir-CpX for <dnsop@ietfa.amsl.com>; Tue, 12 Jun 2018 19:28:20 -0700 (PDT)
Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 EFD13126F72 for <dnsop@ietf.org>; Tue, 12 Jun 2018 19:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1528856899; x=2392770499; 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=/JXwA2INf/LZHv40ZC0ems4b3dCbyRsW+NTkXU1jMBQ=; b=ff7yYaQyxjkjc9ygOwWdr5kU5Pf91XHtzIyd10KKB5ba/7wxaa5hRJjOgBeWPW9q SJdtrgw8UdkBbn08Hacgzua87d/lp3ku6mu8J63d/j3w8Zv7Crn3sRzC3p3RvMH4 8RE6YC6jly+nSTOM9Glg9TG/JcIRCB3ovO1q4CeGnQfjLsqDQ3tcZvSO+LYYtXIS uxX/Eo3OX9MoHD73G/SmHpymb1wuK71grNrmG+iJgK+jiTbPu5n9NZJjf1OCPvX/ OB+mxBVWWsagGQtmhyz02ln5THU5NlfarbjyHO8cavcrYk9UFUppfCDkRorPmY8P eRVtppG0nezNSVyZdVt6Uw==;
X-AuditID: 11ab0217-24b109e000003e90-28-5b2081426d8e
Received: from mr2-mtap-s01.rno.apple.com (mr2-mtap-s01.rno.apple.com [17.179.226.133]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 1E.96.16016.241802B5; Tue, 12 Jun 2018 19:28:19 -0700 (PDT)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_qTOtcWP5HQnSzhlu9/Y4Rw)"
Received: from apple.com (nwk-grpmailp-qapp15.corp.apple.com [17.146.97.143]) by mr2-mtap-s01.rno.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180329 64bit (built Mar 29 2018)) with ESMTPS id <0PA8007EJPJ58UB0@mr2-mtap-s01.rno.apple.com>; Tue, 12 Jun 2018 19:28:17 -0700 (PDT)
Received: from nwk-grpmailp-qapp15.corp.apple.com (nwk-grpmailp-qapp15.corp.apple.com [127.0.0.1]) by pps.post-v (8.16.0.20/8.16.0.20) with SMTP id w5D2SHwc028569; Tue, 12 Jun 2018 19:28:17 -0700
Received: from [17.234.6.103] ([17.234.6.103]) by nwk-mmpp-sz11.apple.com with ESMTP id 0PA800LYBPI4OR70; Tue, 12 Jun 2018 19:28:17 -0700
Received: from [17.234.6.103] by nwk-mmpp-sz11.apple.com with ESMTPSA; Tue, 12 Jun 2018 19:28:17 -0700 (PDT)
From: David Schinazi <dschinazi@apple.com>
Message-id: <43D81243-B2D8-4622-B03D-D20DB7EC243C@apple.com>
Date: Tue, 12 Jun 2018 19:28:16 -0700
In-reply-to: <FAA35F1A-9AD4-4993-9A5C-53A6143B9DE7@isc.org>
Cc: dnsop <dnsop@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>, Michelle Cotton via RT <iana-questions@iana.org>, Stuart Cheshire <cheshire@apple.com>
To: 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>
X-Mailer: Apple Mail (2.3445.5.20)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-06-12_14:,, signatures=0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUiuPlRq65zo0K0wfoTnBZ331xmsWhdvZTd 4sqL+ywWp4/tZXZg8eiR91iy5CeTx4PH75gDmKO4bFJSczLLUov07RK4Mva3T2IveN7BWPF9 2UL2BsbTZV2MnBwSAiYSrU3bWbsYuTiEBA4yScz99ZEVJMErICjxY/I9FhCbWSBMYunMJ8wQ RauZJM7vusUOkhASOMkoMX2tNkSim1Hi3bepbBCJPIl511uZuhg5ONgEtCQOrDGCGGoj8eHs L7ChwgIhEs9u9jOC2CwCqhJXHywEa+UUsJZYvX4BE8hMZoE5jBIzb/4AS4gIKEi0vX3FBDG/ QGLv3C42iBeUJKZ/vw1lZ0tMXLyUZQKj0CwkT8xC8sQsoJOYBdQlpkzJhQhrSzx5d4EVwlaT WPh7EROy+AJGtlWMwrmJmTm6mXlGxnqJBQU5qXrJ+bmbGEGRsppJfAfj59eGhxgFOBiVeHgf XJSPFmJNLCuuzD3EKM3BoiTO+2GXWLSQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxtjTwXLJ F191Rqo/3OcRu3HBw5fFa/bbPN5aoGFwKzKns1Die3Remy3PxhaWgqjebg5HqyX3OS0fnvin c5qNmWv+N+eeRfN3z6567lJj7Tk7S3SVYN6MP/3BFZJlB7KeXXvgIukVMXmhUq2dhURVdkrJ puv9Dd5XDUX1DxvMtlJs2JVR/vCIEktxRqKhFnNRcSIAVqdN0XUCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wMUaJHEjqpeWSWfX685U2rJJp-4>
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: Wed, 13 Jun 2018 02:28:28 -0000
Hi everyone, Stuart and I have a draft that attempts to address these issues, please let us know if you think it does or doesn't. https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa <https://tools.ietf.org/html/draft-cheshire-sudn-ipv4only-dot-arpa> Thanks, David Schinazi > On Jun 12, 2018, at 18:29, Mark Andrews <marka@isc.org> wrote: > > The Domain Name Reservation Considerations in RFC 7050 do not cover whether > a delegation should be signed or not. Due to that omission in constructing the set > of questions to be asked RFC 7050 fails when the client is behind a validating resolver > that has NO SPECIAL KNOWLEDGE of IPV4ONLY.ARPA. > > There are 2 pieces of work that are required. > 1) update the list of questions that need to be asked needs to include whether a delegation > needs to be signed or not. > 2) update RFC 7050 to include explicit instructions to say DO NOT sign IPV4ONLY.ARPA. > > Item 1 is dnsop work as far as I can see. Item 2, I think, should be v6ops work. > > HOME.ARPA is a example of a unsigned delegation. > 10.IN-ADDR.ARPA is a example of a unsigned delegation. > > There is zero benefit in IPV4ONLY.ARPA being signed. Its contents on the Internet > are well known. The contents with NAT64 in using are well known except for the > AAAA query. The answer to that query is *expected to change*. That answer cannot > be validated. > > Mark > >> Begin forwarded message: >> >> From: "Michelle Cotton via RT" <iana-questions@iana.org <mailto:iana-questions@iana.org>> >> Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure. >> Date: 6 January 2018 at 8:45:10 am AEDT >> To: marka@isc.org <mailto:marka@isc.org> >> Reply-To: iana-questions@iana.org <mailto:iana-questions@iana.org> >> >> Hello, >> >> Following up on a thread from the end of the year. Who will bring this to the DNSOps working group? Will someone notify us if there is an consensus on a conclusion of what needs to be done? >> >> Thanks in advance. >> >> --Michelle Cotton >> >> >> On Sun Dec 10 22:40:29 2017, danwing@gmail.com <mailto:danwing@gmail.com> wrote: >>> I had replied to the errata. I agree it warrants additional >>> discussion, and had also suggested same. Dnsops seems appropriate. >>> >>> >>> >>> The question is not to much where the attacker is, but what DNSSEC >>> guarantee is provided. DNS64 imagines the client could do its own >>> validation — if it wanted. To date, effectively zero clients seem to >>> want to do their own DNSSEC validation. >>> >>> -d >>> >>>> On Dec 10, 2017, at 11:13 AM, Savolainen, Teemu (Nokia-TECH/Tampere) >>>> <teemu.savolainen@nokia.com <mailto:teemu.savolainen@nokia.com>> wrote: >>>> >>>> Hi, >>>> >>>> Dan Wing seem to have moved to VMWare, but cc'ing him now with an >>>> email address I found from an I-D.. >>>> >>>> I'm not really following IETF nowadays, so I don't know if this has >>>> been discussed. >>>> >>>> Also I'm not sure why ISPs couldn’t first verify the A response's >>>> validity and then generate AAAA response to the client as document... >>>> but I suppose it could be considered to be more proper action to >>>> modify insecure responses than secure responses. I'm just worried >>>> what happens if there's attacker between ISP and root, in which case >>>> the IPv4 address part of the response could be modified by attacker >>>> and then delivered to client in the ISP's synthetic AAAA record.. >>>> >>>> So I cannot accept the errata straight away, but it should be >>>> discussed with people who are more experts on this than I am. >>>> >>>> Best regards, >>>> >>>> Teemu >>>> >>>> >>>> -----Original Message----- >>>> From: Michelle Cotton via RT [mailto:iana-questions- >>>> comment@iana.org <mailto:comment@iana.org>] >>>> Sent: 9. joulukuuta 2017 1:22 >>>> Cc: ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>; spencerdawkins.ietf@gmail.com <mailto:spencerdawkins.ietf@gmail.com>; >>>> jouni.nospam@gmail.com <mailto:jouni.nospam@gmail.com>; Savolainen, Teemu (Nokia-TECH/Tampere) >>>> <teemu.savolainen@nokia.com <mailto:teemu.savolainen@nokia.com>> >>>> Subject: [IANA #989438] ipv4only.arpa's delegation should be >>>> insecure. >>>> >>>> Hello, >>>> >>>> Just checking to see if anyone had a chance to look at this. >>>> Dan Wing's email addressed bounced (dwing@cisco.com <mailto:dwing@cisco.com>). >>>> >>>> Thanks, >>>> Michelle >>>> >>>> >>>> >>>>> On Tue Nov 28 14:43:00 2017, michelle.cotton wrote: >>>>> Hello Authors and Area Directors, >>>>> >>>>> We have received a message pointing out an errata report that would >>>>> modify the actions that were performed for RFC7050. >>>>> >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-> >>>>> 2Deditor.org_errata_eid5152&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IMDU0f3LtPMQf5XkZ06fNg&m=hjPiqrkJLcvBw1fuqRPXMX6h76vuapCYz_DxRRq7SkM&s=uCKCSggUUCCU7iPuRs- >>>>> usGcL3T69Fia9gTOy4UQwhLk&e= >>>>> >>>>> Has this report been discussed? Will the result be an approved >>>>> errata >>>>> report or a new RFC? >>>>> >>>>> Thanks in advance. >>>>> >>>>> Michelle Cotton >>>>> Protocol Parameters Engagement Sr. Manager >>>> >>>> >>>> >> >> >> > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org <mailto:marka@isc.org> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Mark Andrews
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Ted Lemon
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… David Schinazi
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Warren Kumari
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… JORDI PALET MARTINEZ
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Philip Homburg
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Mark Andrews
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… Ted Lemon
- Re: [DNSOP] [v6ops] [IANA #989438] ipv4only.arpa'… David Schinazi
- [DNSOP] Fwd: [IANA #989438] ipv4only.arpa's deleg… Mark Andrews