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

On Tue, Jun 12, 2018 at 11:16 PM Mark Andrews <marka@isc.org> wrote:

>
> > On 13 Jun 2018, at 12:28 pm, David Schinazi <dschinazi@apple.com> 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.
> 
>

I'm not sure that I agree with you on that (let's ignore DNSSEC for now) --
there is little *technical* reason for the normal DNS resolution process to
know that ipv4only.arpa is special, but administrators sometimes install
ipv4only.arpa resolution locally (for disconnected networks, to improve
reliability (e.g when .arpa is slow), or when users are using non-local DNS
resolvers (like 8.8.8.8). This is not a technical thing, but rather a
blessing that NAT64 / DNS64 admins can do that -- personally this sounds
more like an argument for adding it to locally served zones not SUDN. What
am I missing here?

>
> The document needs to explicitly state that the delegation for
> IPV4ONLY.ARPA in ARPA MUST
> be insecure (no DS record).
>
>
RFC7050 Section 7 says:
"A signed "ipv4only.arpa." allows validating
   DNS64 servers (see [RFC6147] Section 3, Case 5, for example) to
   detect malicious AAAA resource records.  Therefore, the zone serving
   the well-known name has to be protected with DNSSEC."

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...

> 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
>

W

>
> >> 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>
> >>> 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
> >>
> >> _______________________________________________
> >> v6ops mailing list
> >> v6ops@ietf.org
> >> https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka@isc.org
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf