Sun 18 March 2018 | -- (permalink)

Roy Arends gave a talk at today's IEPG meeting about a DNSSEC outage caused by an attempt to combine a DS hash algorithm roll with a type of key roll called a "KSK Double-DS" roll. Roy analyzed the problem that occurred in some detail, I'll post a link here when his slides become available, but he got me wondering why anybody would even try the KSK Double-DS stunt in the first place.

To me, the obvious way to do a DNSSEC KSK roll is the other approach documented in RFC 6781, called the "Double-Signature" method.

Leaving aside the oops that Roy reported (which has no direct analog with the Double-Signature method), the Double-DS approach requires multiple interactions with the parent zone, which is one of the most error prone parts of the entire process. With Double-Signature, I can add the new DSKEY RR, update the child zone, and verify it, all without bothering anybody else, particularly if I'm using a signing setup where I can check the signed updated zone before putting it in service (static compilation with dnssec-signzone, hidden signing master, whatever). Yeah, the stage where one asks the parent zone to replace the DS RR is scary, but that's unavoidable, and the failure modes for the DS change are simpler than for Double-DS.

Just say "no" to Double-DS.