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 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.]
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.
> > 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.
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.
>
> ... and by doing so we could increase the complexity somewhere else.
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
