Hi, (no hats, just experience)
> On Nov 16, 2016, at 2:34 AM, Mark Andrews <[email protected]> wrote: > > In message > <CAPt1N1=5kyxa7xld3ks6y+t+0swsxcdxutozbvw4ed3ewpq...@mail.gmail.com> > , Ted Lemon writes: >> Well, yes, but it means that we need to ask ICANN to do an insecure >> delegation, and there isn't a process for that. > > We are adults. They are adults. We can talk together. That should > be all the process needed once there is consensus that the name and > delegation are needed for protocol reasons. Just for clarity: I have complete faith that this is true, but it’s important to appreciate the position ICANN may be put in if we ask the IANA to do an unsigned delegation in the root zone. This was Andrew’s initial point and it shouldn’t be lost: * RFC 6761 creates a registry for special use domain names. There have been many fine arguments over a couple of years now in DNSOP about exactly what implications this registry has for the DNS and the usefulness of the domain name space generally, but from the process perspective, it’s an IETF registry, over which the IETF has policy authority to request an update. * the DNS root zone is a different registry, for which explicit policy authority lies outside of the IETF: not with IANA, or even ICANN-the-corporation, but with the naming community. The special use domain name registry created in RFC 6761 implies an expectation that the policy authority for the root zone will not take certain hypothetical future actions. But an update to it does not ask for a change to the DNS root zone registry. If the IETF asks for an unsigned delegation in the root for a special use name, it’s requesting an update to the DNS root zone, for which neither ICANN nor IANA alone has the responsibility. The practical implications of this, as Andrew noted, are unknown at this time— everyone who spoke in homenet yesterday about what ICANN could, should, or would do was speculating— but might very well include some level of need to consult the naming community. There are processes for that, but they take time and may not turn out the way we’d like. I note again that this is not about what string is being requested, or about whether the IETF should consult ICANN about the special use names registry established in RFC 6761. It’s about a new process for requesting a new kind of change to the DNS root zone registry. As I said at the mic yesterday: a second-level name under .arpa avoids this registry authority problem altogether. I understand the concern that the resulting names are ugly, but the policy authority over .arpa is held by the IETF community, via the IAB. The process of asking the IAB for an unsigned delegation in .arpa is defined already, and is likely to be vastly simpler and faster than any such process for requesting an unsigned delegation in the root zone. Suzanne > >> On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews <[email protected]> wrote: >>> >>> In message <[email protected]. >> com> >>> , Ted Lemon writes: >>>> Yeah, this sunk in for all of us when we were standing around outside >>>> the meeting room kvetching. It's a bit of a conundrum. >>> >>> No. >>> >>> All it means is that there isn't policy for this which is exactly >>> the correct state of affairs for special names in the root namespace. >>> Each name needs to be individually handled as each is special with >>> its own requirements. >>> >>> Mark >>> >>>> On Wed, Nov 16, 2016 at 3:30 PM, Mark Andrews <[email protected]> wrote: >>>>> >>>>> In message <[email protected]>, Andrew Sullivan wri >> tes >>>> : >>>>>> Hi, >>>>>> >>>>>> Mark Andrews's point about a DNSSEC insecure delegation today was not >>>>>> I think fully appreciated. >>>>>> >>>>>> In order to create a top-most label in the domain name that can be >>>>>> used this way and that has the necessary properties, we cannot simply >>>>>> instruct IANA to do it. That is in fact creating a delegation in the >>>>>> root zone of the DNS. I believe that RFC 2860 (the MoU between the >>>>>> IETF and ICANN) does allow us to create special-use domain names at >>>>>> the top-most level. But I do not believe it allows us to create >>>>>> special-use domain names at the top-most level _in the DNS_, because >>>>>> that is control of the root zone and it is unambiguously the province >>>>>> of ICANN. >>>>>> >>>>>> Therefore, if the WG decides to use a top-level label for these >>>>>> purposes, we have to apply to ICANN to get it delegated from the root >>>>>> in a provably insecure fashion. Interestingly, ICANN actually has a >>>>>> policy that it won't delegate things from the root any more that are >>>>>> _not_ DNSSEC signed, and the whole point here is in fact to add an >>>>>> entry that is contrary to that policy, so getting such a delegation >>>>>> would require ICANN to change its policies before it could happen. >>>>> >>>>> I suspect this is a mischaracterization of the policy. GTLD >>>>> delegations are so constrained. This is not a GTLD delegation. >>>>> >>>>> New country code delegations are not so constrained. >>>>> >>>>> We are not asking them to delegate away from the roots. >>>>> >>>>> root zone: >>>>> HOMENET. NS A.ROOT-SERVERS.NET. >>>>> ... >>>>> HOMENET. NS M.ROOT-SERVERS.NET. >>>>> >>>>> homenet zone: >>>>> HOMENET. SOA a.root-servers.net. nstld.verisign-grs.com. 1 1800 900 6048 >> 00 >>>> 86400 >>>>> HOMENET. NS A.ROOT-SERVERS.NET. >>>>> ... >>>>> HOMENET. NS M.ROOT-SERVERS.NET. >>>>> >>>>> B.T.W. this should also be done for .ONION and .LOCAL if we want >>>>> local DNS resolvers to intercept these queries. DNSSEC keeps >>>>> getting forgotten. The only reason people aren't screaming >>>>> is that there are very few validating clients and the both >>>>> .ONION and .LOCAL don't use the DNS. SERVFAIL is nearly as >>>>> good as NXDOMAIN for these use cases. >>>>> >>>>> HOMENET uses the DNS. If one can get a trust anchor for HOMENET >>>>> installed in every validator there shouldn't be any queries for >>>>> HOMENET/DS. >>>>> >>>>>> That is an important practical fact that ought to be taken into >>>>>> consideration when deciding what kind of label to use. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> A >>>>>> >>>>>> -- >>>>>> Andrew Sullivan >>>>>> [email protected] >>>>>> >>>>>> _______________________________________________ >>>>>> homenet mailing list >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>> -- >>>>> Mark Andrews, ISC >>>>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>>>> PHONE: +61 2 9871 4742 INTERNET: [email protected] >>>>> >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/homenet >>> -- >>> Mark Andrews, ISC >>> 1 Seymour St., Dundas Valley, NSW 2117, Australia >>> PHONE: +61 2 9871 4742 INTERNET: [email protected] > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: [email protected] > > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
