On 3/10/22 1:16 PM, Colm MacCárthaigh wrote:
I think a single BCP doc is a good idea, but here I'd actually go much further and argue for a significant section in the BCP that acknowledges that it is also a best current practice not to enable DNSSEC. That is objectively the most common practice, and it is very often intentional.

I'm not trying to get into what is and isn't best current practice.

But I do think that best and common practices often do differ. I also think that just because something is the most common practice doesn't equate to being the best practice. -- History is full of things that were once the most common that we would now agree aren't now and probably weren't at the time the /best/ thing to be done.

I think there's a way to frame it and lay out the intrinsic trade-offs between internet stability risks and the security benefits. That framing actually underscores the importance and urgency of all the best practices that can mitigate the stability risks and enhance the security.

Agreed. It is important to understand and articulate all (known) aspects of a problem as well as the pros and cons thereto.

That might more effectively persuade DNSSEC skeptics. Absent a big change in adoption, a BCP could otherwise seem quite disconnected from reality (TLD-scale outages, stale cryptography) and tone-deaf to the skepticism that's out there. "We hear you" is powerful.

We see such disconnects between BCPs (not smoking / wearing seat belts) and people choosing to go against them (by smoking / not wearing seat belts). Such choices don't inherently detract from the veracity of the BCP. -- I know a lot of people that say things like "I know that I should do $THING, but I don't like it, so I choose not do $THING." As much as I dislike it, I have to respect their personal choice. At least up until their choice adversely impacts me / others.



--
Grant. . . .
unix || die

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to