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

LGTM.   It sounds like Mark is arguing that RFC6761 also needs updated.
Possibly this document could do that, but it would need to be reframed a
bit.

On Tue, Jun 12, 2018 at 7: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
>
>
> 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
>
>
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>