In message <CAPt1N1=qPiq1g1Dtomp4=t98pdbzde0o3to7rcayomxj+3w...@mail.gmail.com> , Ted Lemon writes: > > The problem is that the consensus process has to include them and we don't > know how to do that.
We have ways to talk to ICANN both formally and informally. I suggest we talk to them. It may be as simple as add it to IANA considerations in the special name defining RFC. That would be what I would do. The special names process delegates the name space to us. Mark > On Nov 16, 2016 16:35, "Mark Andrews" <[email protected]> wrote: > > > > > In message <CAPt1N1=5KyXA7XLd3Ks6y+T+0SWSXcdXUTozbVw4ed3EwpQTYA@ > > 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. > > > > > On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews <[email protected]> wrote: > > > > > > > > In message <CAPt1N1m_btPK8TGugoYd7iWxU6sEkPM288biBM > > [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] > > > > --001a114102c073b9620541662164 > Content-Type: text/html; charset=UTF-8 > Content-Transfer-Encoding: quoted-printable > > <p dir=3D"ltr">The problem is that the consensus process has to include the= > m and we don't know how to do that. </p> > <div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Nov 16, 2016 1= > 6:35, "Mark Andrews" <<a href=3D"mailto:[email protected]";>marka@i= > sc.org</a>> wrote:<br type=3D"attribution"><blockquote class=3D"gmail_qu= > ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex= > "><br> > In message <CAPt1N1=3D<a href=3D"mailto:5KyXA7XLd3Ks6y%2BT%2B0SWSXcdXUTo= > [email protected]">5KyXA7XLd3Ks6y+T+<wbr>0SWSXcdXUTozbVw4ed3Ew= > pQTYA@<wbr>mail.gmail.com</a>><br> > , Ted Lemon writes:<br> > > Well, yes, but it means that we need to ask ICANN to do an insecure<br= > > > > delegation, and there isn't a process for that.<br> > <br> > We are adults.=C2=A0 They are adults.=C2=A0 We can talk together.=C2=A0 Tha= > t should<br> > be all the process needed once there is consensus that the name and<br> > delegation are needed for protocol reasons.<br> > <br> > > On Wed, Nov 16, 2016 at 4:28 PM, Mark Andrews <<a href=3D"mailto:ma= > [email protected]">[email protected]</a>> wrote:<br> > > ><br> > > > In message <CAPt1N1m_<wbr>btPK8TGugoYd7iWxU6sEkPM288biBM<wbr>3= > [email protected].<br> > > com><br> > > > , Ted Lemon writes:<br> > > >> Yeah, this sunk in for all of us when we were standing around= > outside<br> > > >> the meeting room kvetching.=C2=A0 =C2=A0It's a bit of a c= > onundrum.<br> > > ><br> > > > No.<br> > > ><br> > > > All it means is that there isn't policy for this which is exa= > ctly<br> > > > the correct state of affairs for special names in the root namesp= > ace.<br> > > > Each name needs to be individually handled as each is special wit= > h<br> > > > its own requirements.<br> > > ><br> > > > Mark<br> > > ><br> > > >> On Wed, Nov 16, 2016 at 3:30 PM, Mark Andrews <<a href=3D"= > mailto:[email protected]";>[email protected]</a>> wrote:<br> > > >> ><br> > > >> > In message <<a href=3D"mailto:20161116054604.GB55057@= > mx2.yitter.info">20161116054604.GB55057@mx2.<wbr>yitter.info</a>>, Andre= > w Sullivan wri<br> > > tes<br> > > >> :<br> > > >> >> Hi,<br> > > >> >><br> > > >> >> Mark Andrews's point about a DNSSEC insecure del= > egation today was not<br> > > >> >> I think fully appreciated.<br> > > >> >><br> > > >> >> In order to create a top-most label in the domain na= > me that can be<br> > > >> >> used this way and that has the necessary properties,= > we cannot simply<br> > > >> >> instruct IANA to do it.=C2=A0 That is in fact creati= > ng a delegation in the<br> > > >> >> root zone of the DNS.=C2=A0 I believe that RFC 2860 = > (the MoU between the<br> > > >> >> IETF and ICANN) does allow us to create special-use = > domain names at<br> > > >> >> the top-most level.=C2=A0 But I do not believe it al= > lows us to create<br> > > >> >> special-use domain names at the top-most level _in t= > he DNS_, because<br> > > >> >> that is control of the root zone and it is unambiguo= > usly the province<br> > > >> >> of ICANN.<br> > > >> >><br> > > >> >> Therefore, if the WG decides to use a top-level labe= > l for these<br> > > >> >> purposes, we have to apply to ICANN to get it delega= > ted from the root<br> > > >> >> in a provably insecure fashion.=C2=A0 Interestingly,= > ICANN actually has a<br> > > >> >> policy that it won't delegate things from the ro= > ot any more that are<br> > > >> >> _not_ DNSSEC signed, and the whole point here is in = > fact to add an<br> > > >> >> entry that is contrary to that policy, so getting su= > ch a delegation<br> > > >> >> would require ICANN to change its policies before it= > could happen.<br> > > >> ><br> > > >> > I suspect this is a mischaracterization of the policy.= > =C2=A0 GTLD<br> > > >> > delegations are so constrained.=C2=A0 This is not a GTLD= > delegation.<br> > > >> ><br> > > >> > New country code delegations are not so constrained.<br> > > >> ><br> > > >> > We are not asking them to delegate away from the roots.<= > br> > > >> ><br> > > >> > root zone:<br> > > >> > HOMENET. NS <a href=3D"http://A.ROOT-SERVERS.NET"; rel=3D= > "noreferrer" target=3D"_blank">A.ROOT-SERVERS.NET</a>.<br> > > >> > ...<br> > > >> > HOMENET. NS <a href=3D"http://M.ROOT-SERVERS.NET"; rel=3D= > "noreferrer" target=3D"_blank">M.ROOT-SERVERS.NET</a>.<br> > > >> ><br> > > >> > homenet zone:<br> > > >> > HOMENET. SOA <a href=3D"http://a.root-servers.net"; rel= > =3D"noreferrer" target=3D"_blank">a.root-servers.net</a>. <a href=3D"http:/= > /nstld.verisign-grs.com" rel=3D"noreferrer" target=3D"_blank">nstld.verisig= > n-grs.com</a>. 1 1800 900 6048<br> > > 00<br> > > >> 86400<br> > > >> > HOMENET. NS <a href=3D"http://A.ROOT-SERVERS.NET"; rel=3D= > "noreferrer" target=3D"_blank">A.ROOT-SERVERS.NET</a>.<br> > > >> > ...<br> > > >> > HOMENET. NS <a href=3D"http://M.ROOT-SERVERS.NET"; rel=3D= > "noreferrer" target=3D"_blank">M.ROOT-SERVERS.NET</a>.<br> > > >> ><br> > > >> > B.T.W. this should also be done for .ONION and .LOCAL if= > we want<br> > > >> > local DNS resolvers to intercept these queries.=C2=A0 DN= > SSEC keeps<br> > > >> > getting forgotten.=C2=A0 The only reason people aren'= > ;t screaming<br> > > >> > is that there are very few validating clients and the bo= > th<br> > > >> > .ONION and .LOCAL don't use the DNS.=C2=A0 SERVFAIL = > is nearly as<br> > > >> > good as NXDOMAIN for these use cases.<br> > > >> ><br> > > >> > HOMENET uses the DNS.=C2=A0 If one can get a trust ancho= > r for HOMENET<br> > > >> > installed in every validator there shouldn't be any = > queries for<br> > > >> > HOMENET/DS.<br> > > >> ><br> > > >> >> That is an important practical fact that ought to be= > taken into<br> > > >> >> consideration when deciding what kind of label to us= > e.<br> > > >> >><br> > > >> >> Best regards,<br> > > >> >><br> > > >> >> A<br> > > >> >><br> > > >> >> --<br> > > >> >> Andrew Sullivan<br> > > >> >> <a href=3D"mailto:[email protected]";>ajs@anvilw= > alrusden.com</a><br> > > >> >><br> > > >> >> ______________________________<wbr>_________________= > <br> > > >> >> homenet mailing list<br> > > >> >> <a href=3D"mailto:[email protected]";>[email protected]= > </a><br> > > >> >> <a href=3D"https://www.ietf.org/mailman/listinfo/hom= > enet" rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/<wb= > r>listinfo/homenet</a><br> > > >> > --<br> > > >> > Mark Andrews, ISC<br> > > >> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > > >> > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= > =C2=A0 =C2=A0 =C2=A0 =C2=A0INTERNET: <a href=3D"mailto:[email protected]";>mark= > [email protected]</a><br> > > >> ><br> > > >> > ______________________________<wbr>_________________<br> > > >> > homenet mailing list<br> > > >> > <a href=3D"mailto:[email protected]";>[email protected]</a>= > <br> > > >> > <a href=3D"https://www.ietf.org/mailman/listinfo/homenet= > " rel=3D"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/<wbr>li= > stinfo/homenet</a><br> > > > --<br> > > > Mark Andrews, ISC<br> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > > > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = > =C2=A0 =C2=A0 =C2=A0INTERNET: <a href=3D"mailto:[email protected]";>[email protected]= > g</a><br> > --<br> > Mark Andrews, ISC<br> > 1 Seymour St., Dundas Valley, NSW 2117, Australia<br> > PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= > =A0 =C2=A0INTERNET: <a href=3D"mailto:[email protected]";>[email protected]</a><br> > </blockquote></div></div> > > --001a114102c073b9620541662164-- -- 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
