In the .se zone dnssec penetration is quite high (approx. 50%). And validation is high in Sweden too, all major ISPs validate. Government agencies and government owned companies in Sweden are required to sign their zones. Not all do it - yet, but we are working on it. Our goal is to drive .se to become 100% signed.
100% signed would mean unsigned zones do not get delegated, going insecure is no longer an option. I would like the protocol to be able to handle that case. The “easy” solution is to require lax-validation. It doesn’t make a zone less secure and allows to transfer zones between operators using different algorithms. /Ulrich > > > >> On 1 Mar 2021, at 14:14, Joe Abley <jab...@hopcount.ca >> <mailto:jab...@hopcount.ca>> wrote: >> >> Hi Ulrich, >> >> On Mar 1, 2021, at 05:43, Ulrich Wisser <ulr...@wisser.se >> <mailto:ulr...@wisser.se>> wrote: >> >>> On 25 Feb 2021, at 16:11, Joe Abley <jab...@hopcount.ca >>> <mailto:jab...@hopcount.ca>> wrote: >> >>> >> >>>> On Feb 25, 2021, at 06:53, Ulrich Wisser >>>> <ulrich=40wisser...@dmarc.ietf.org >>>> <mailto:ulrich=40wisser...@dmarc.ietf.org>> wrote: >> >>> >>>>> But this is a real world problem, one that is holding DNSSEC back. >>>>> If you buy DNS operations the operator will usually tell you what >>>>> algorithm they use, you have no choice in that. >>>> >>>> This feels like one of those areas where more specificity is needed. "DNS >>>> operations" is is over-broad; what you mean, I think, is "if you outsource >>>> zone-signing". If you sign yourself and distribute your zone to external >>>> DNS operators then you can add and drop vendors without worrying about key >>>> rollovers, for example. >>> >>> Ok, I can be more specific. >>> >>> As a small business owner you have no way to move your hosting company to >>> change their DNSSEC configuration. (Besides that you most probably have no >>> idea that it exists.) You should be able to switch hosting providers >>> without thinking about security, a secure transition should be guaranteed >>> by the hosting companies, who can only do it if it is enabled by the >>> protocol. >> >> Even this really requires more specificity. What is a "hosting company"? >> >> I think a lot of the problems we face with these kinds of scenarios is that >> various functionally-overlapping industries have sprung up without DNSSEC >> being much more than an afterthought in the way that products are structured >> and sold. It's perhaps unremarkable that the mechanics of offering these >> services are not a great fit. >> >> We can try harder and harder to shoe-horn DNSSEC into products that don't >> easily accommodate it, for sure. However, there's an attendant risk that by >> doing so all we really achieve is making DNSSEC more operationally complex >> than it already is, and I think there's an argument that such an outcome >> would not make it easier to deploy. >> >>> As a larger entity you might have compliance requirements for dnssec. >> >> [As an entity large enough to pay significant fees for enterprise DNS >> service, the reality today is that you probably don't use DNSSEC at all.] >> >>>> DNSSEC is normally part of a layered set of defences. In such an >>>> architecture relaxing one layer for a period in order to fix a problem or >>>> avoid a more complicated transition can be a perfectly acceptable answer. >>>> Going insecure for a short period in that context is not necessarily a >>>> cop-out; it could well be smart thinking. >>> >>> I totally disagree. When has switching off security ever been a smart >>> option? >> >> If security was the only consideration, then nobody would connect anything >> to a network in the first place. >> >>> It is only considered smart because the process of moving is so complex and >>> error prone. >>> And that is a “feature” of the protocol design. It’s not a law of nature. >>> We could change the design to allow for secure transfer. >> >> ... and by doing so we could increase the complexity somewhere else. >> >> I'm really just pushing back on the idea that going insecure for a planned, >> controlled period of time is necessarily a terrible idea. I often see these >> kinds of reactions from people seeing particular security measures as binary >> options, instead of taking a more holistic and risk-based approach, which is >> why my knee is jerking (I'm not suggesting that you are one of them). >> >> If I rely upon a DNS vendor to sign my zone and I want to change vendors for >> some business reason, being able to switch easily at the cost of going >> insecure for 6 hours might be a much better answer than not being able to >> switch at all, or even having the cost of switching amplified by 100 >> person-hours of planning, or dealing with the risk of going dark to users >> downstream of 8.8.8.8 when it turns out that the change triggers another >> corner-case in Google's code base. >> >> To the end-user, I can see why having a protocol element designed to make >> this easier and avoid the practical need to go insecure seems highly >> attractive, but we're really just shifting the cost of dealing with what >> might very well be a somewhat rare corner case to the developers, operators >> and users of every DNS server that supports DNSSEC. Even if the costs are >> low in the latter case, I think it's reasonable to say they are non-zero and >> universal, which means they might not be so low in aggregate. >> >> In this context, the determination of what is smart and what is silly seems >> a little more grey to me than your message ("totally") suggests. >> >> >> Joe >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
