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

[Mark Andrews <[e-mail]>]

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" <[e-mail]>
> Subject: [IANA #989438] ipv4only.arpa's delegation should be insecure.
> Date: 6 January 2018 at 8:45:10 am AEDT
> To: [e-mail]
> Reply-To: [e-mail]
> 
> 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, [e-mail] 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)
>>> <[e-mail]> 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-
>>> [e-mail]]
>>> Sent: 9. joulukuuta 2017 1:22
>>> Cc: [e-mail]; [e-mail];
>>> [e-mail]; Savolainen, Teemu (Nokia-TECH/Tampere)
>>> <[e-mail]>
>>> 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 ([e-mail]).
>>> 
>>> 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: [phone]              INTERNET: [e-mail]