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

Mark Andrews <marka@isc.org> Wed, 13 June 2018 01:29 UTC

Return-Path: <marka@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 28E65130DC6; Tue, 12 Jun 2018 18:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id L2584IejuVLj; Tue, 12 Jun 2018 18:29:38 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org []) (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 F0ED812777C; Tue, 12 Jun 2018 18:29:37 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C898B3AB007; Wed, 13 Jun 2018 01:29:35 +0000 (UTC)
Received: from zmx1.isc.org (localhost []) by zmx1.isc.org (Postfix) with ESMTPS id A86FB160050; Wed, 13 Jun 2018 01:29:35 +0000 (UTC)
Received: from localhost (localhost []) by zmx1.isc.org (Postfix) with ESMTP id 818D616006C; Wed, 13 Jun 2018 01:29:35 +0000 (UTC)
Received: from zmx1.isc.org ([]) by localhost (zmx1.isc.org []) (amavisd-new, port 10026) with ESMTP id TBMGjsgf0sYl; Wed, 13 Jun 2018 01:29:35 +0000 (UTC)
Received: from [] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au []) by zmx1.isc.org (Postfix) with ESMTPSA id 46A73160050; Wed, 13 Jun 2018 01:29:34 +0000 (UTC)
From: Mark Andrews <marka@isc.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F9CB04F-A666-452E-85E9-4B0B867A3F0F"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Wed, 13 Jun 2018 11:29:31 +1000
References: <rt-4.2.9-2607-1515188710-296.989438-6-0@icann.org>
Cc: Michelle Cotton via RT <iana-questions@iana.org>
To: dnsop <dnsop@ietf.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Message-Id: <FAA35F1A-9AD4-4993-9A5C-53A6143B9DE7@isc.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zbcQhok-dCE8kh6C6KofBL1tAXY>
Subject: [DNSOP] Fwd: [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 01:29:42 -0000

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

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.


> Begin forwarded message:
> From: "Michelle Cotton via RT" <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
> Reply-To: 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 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> 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]
>>> Sent: 9. joulukuuta 2017 1:22
>>> Cc: ietf@kuehlewind.net; spencerdawkins.ietf@gmail.com;
>>> jouni.nospam@gmail.com; Savolainen, Teemu (Nokia-TECH/Tampere)
>>> <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).
>>> 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-
>>>> 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