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

[Mark Andrews <[e-mail]>]

> On 13 Jun 2018, at 12:28 pm, David Schinazi <[e-mail]> wrote:
> 
> 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
> 
> Thanks,
> David Schinazi
> 

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.  That would
allow getaddrinfo() to be able to lookup up the AAAA records without any intermediate software
having to special case IPV4ONLY.ARPA.  IPV4ONLY.ARPA would then validate as insecure rather
than as secure as it currently does.

The document needs to explicitly state that the delegation for IPV4ONLY.ARPA in ARPA MUST
be insecure (no DS record).

You then have other issues to deal with like not sending queries for IPV4ONLY.ARPA to servers
which have DNS64 configured or have a local IPV4ONLY.ARPA zone.  These are similar to the issues
for HOME.ARPA but are at the ISP rather than the CPE.

One way to handle that would be for CPE to always use the DHCP/RA DNS servers for IPV4ONLY.ARPA
and require a explicit override just for IPV4ONLY.ARPA.

Another way would be for middle boxes to intercept queries but then you have to account for
anti spoofing technology TSIG, DNS COOKIE etc.  DNS COOKIE just needs the delegated servers
for IPV4ONLY.ARPA to not serve any other zones.  That way any DNS COOKIE state learnt for the
IP addresses of the servers for IPV4ONLY.ARPA does not impact on IPV4ONLY.ARPA lookups.

I mention TSIG because that could be used with a well known TSIG key to defeat fragmentation
attacks and because TSIG can be used between clients and recursive servers that are not
operated by the ISP.  This would be one case where DNS resolution software may want to be
altered by default.  This scenario is even rarer than DNSSEC.

Mark

>> On Jun 12, 2018, at 18:29, Mark Andrews <[e-mail]> 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" <[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]
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]