Subject: Re: [DNSOP] [Ext] DNSSEC Strict Mode

From: Ulrich Wisser <[email-masked]>
Date: Mon, 1 Mar 2021 11:43:20 +0100

> On 25 Feb 2021, at 16:11, Joe Abley <[email-masked]> wrote:
> 
> Hi Ulrich,
> 
> On Feb 25, 2021, at 06:53, Ulrich Wisser <ulrich=[email-masked]> 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.

As a larger entity you might have compliance requirements for dnssec. But at the same time you need to follow public procurement rules. You can not always chose service providers freely. Moving your domain should be secure, going insecure is not an option.

>> Now if your new operator doesn’t use the same algorithm you can’t switch without going insecure.
>> I don’t think this is an acceptable situation.
> 
> I agree that this is a factor that ought to be included in the process of deciding to move vendors. If your proposed new vendor can't do what you want, then presumably you don't move there. While it's always possible to make mistakes, it's not at all clear to me that particular problem is something that needs protocol-level mitigations.
> 
> 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?
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.

> Joe

/Ulrich

---

From: Joe Abley <[email-masked]>
Date: Mon, 1 Mar 2021 08:14:20 -0500

Hi Ulrich,

> 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 swit…

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.]

> 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.

> 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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 1 Mar 2021 13:46:39 -0500

On Mon, Mar 01, 2021 at 08:14:20AM -0500, Joe Abley wrote:

> 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.

I does seem that Ulrich is arguing for updates to the specification that
relax constraints that contribute the operational challenges.  So, if
anything, he's also working to reduce operational complexity.

> [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.]

Yes, presently DNSSEC is enabled on ~5% of domains, and the large
enterprise domains are under-represented.  That's starting to change in
northern Europe (particularly .DK, .NL and .SE), and we just saw on
dns-operations that e.g. irs.gov (yes, not a corporate enterprise) in
the US both publishes and validates DNSSEC.

> If security was the only consideration, then nobody would connect
> anything to a network in the first place.

I think this is a bit too cynical a response.  We're here to take
constructive steps to make things better.

> > 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.
> 

Or not, there is no prior reason why it should be so.

> 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).

Ah, this is fair, we should both work towards making it easier to not go
insecure temporarily, and not sneer at the option of doing so.

> 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.

There is a potential complication if there are business partners or
similar to whom one has made commitments to sign one's domain, and e.g.
publish TLSA records, ...  With the business partners configured to
require DNSSEC validation for some set of network services.  In that
case going insecure is still an outage.

We really should be able to have a minimally painless process of moving
from one DNSSEC provider to another.  Ulrich's suggestions make sense in
that light.  And yet, we also should not sneer at the choice of going
insecure, it just should not be the only (and ideally not most preferred)
option.

-- 
    Viktor.