In message <3e04d8bb-d18f-4d9b-81c3-991bcf76f...@fugue.com>, Ted Lemon writes: > > On Dec 15, 2016, at 4:41 PM, Michael StJohns <m...@nthpermutation.com> > wrote: > > The problem with providing an unsecured delegation for .homenet is that > > items subsidiary to .homenet become spoofable in the wider internet and > > that's not necessarily a good thing. It might make life easier for the > > homenet folks to use the unsecured .homenet local zone, but it might have > > adverse consequences for the non-homenet folken. > > Until every single zone in the DNS is signed, this problem will exist. > This problem would exist if we used .home.arpa. instead of .homenet. If > we want to solve this problem, itâs going to require an extension to the > DNS that provides a way to mark zones of this sort. I would be more > willing to fall on this sword if we actually got more security out of it, > but I donât think we do.
What extension? That there is a break in the chain of trust here? We have that. It's called a insecure delegation. There is NOTHING new being asked for here. Insecure delegations into homes exist for RFC 1918 reverse space. It just works. On can do trust on first contact based on ssid or MAC for hardwired from DHCP/RA. While I don't like RFC 5011, you can use that to roll trusted keys learnt this way. I'd prefer a more CERT like mechanism where there are date constrained records with rdata of "<start> <end> <DS contents>" that are published along with the DNSKEY records. That way you don't need to be always connected like you do with RFC 5011. We you connect back you know whether the TA you have learnt is expected to be valid (inside the time window) or may have expired (after the time window) so bootstrapping may be required again. > The other thing the IETF could say to the homenet working group is simply > "no, you have to solve the naming hierarchy problem on homenets, and you > donât get to have an unsigned delegation at all." But that solution > would have an unreasonably large number of moving parts. I would rather > see us take a step in a direction towards things working, and then based > on our wish that things be more secure, make incremental steps in that > direction. Those incremental steps do not now exist, and requiring any > or all of them as a prerequisite for working service discovery on > homenets is too much. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
