[DNSOP] Fwd: [Ext] DNSSEC Strict Mode

[Ulrich Wisser <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> Hi Ulrich,
>> 
>> On Mar 1, 2021, at 05:43, Ulrich Wisser <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> On 25 Feb 2021, at 16:11, Joe Abley <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> 
>> 
>>>> On Feb 25, 2021, at 06:53, Ulrich Wisser <ulrich=[e-mail] <mailto:ulrich=[e-mail]>> 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
>