[dnssec-deployment] Filling the IANA ITAR

Matt Larson mlarson at verisign.com
Mon Nov 2 13:38:21 EST 2009

On Thu, 29 Oct 2009, Paul Vixie wrote:
> > From: Ray.Bellis at nominet.org.uk
> > Date: Thu, 29 Oct 2009 09:20:16 +0000
> > 
> > It's signed-root only, as per the presentation actually given.
> can you say why?
> (and can matt say why, for com/net?)

On Thu, 29 Oct 2009, Paul Vixie wrote:
> kenneth orr, in _structured requirements definition_, wrote that if there
> are multiple instances of data in several databases or repositories, then
> at least one of them will be (provably) wrong.  i think there's general
> (if anecdotal) agreement on that principle.

Trust anchor rollover scares me.  RFC 5011 is all we've got and today
there is essentially zero deployment.  I don't expect the installed
base to grow quickly, either.  And regardless of the level of RFC 5011
deployment (and proper configuration), if there's a statically
configured trust anchor, there's going to be some amount of collateral
damage to operators who didn't get the message when the trust anchor

All of this can be avoided when one's parent is signed.  Therefore,
the intended trust path to .com and .net is through the
soon-to-be-signed root zone.

On Fri, 30 Oct 2009, Mark Andrews wrote:
> With the root being signed with RSASHA256 there will be a lot of
> validators that still need the ITAR as there will be no trusted
> path from the root for those validators.

There will be no keys for .com and .net in the ITAR, nor will they be
separately published (i.e., on a web site, etc.).

Signing the root with RSASHA256 should be an excellent motivation to
upgrade, which is part of the reasoning: encouraging adoption of newer
validator code with desirable features, such as RFC 5011 support.
(The other important reason is avoiding an algorithm roll.)

The undesirable features would also be flushed out.  In my perfect
world, the first BIND validator that supports RSASHA256 would not
exhibit the DO=1/bufsize=512 fallback behavior.  (I can dream.)

On Sat, 31 Oct 2009, Mark Andrews wrote:
> I don't know whether Verisign is going to use RSASHA256/RSASHA512
> to sign COM and NET but their current statements taken together
> with the fact the root is going to be signed with RSASHA256 requires
> anyone that wants to validate COM or NET to have a validator that
> supports RSASHA256 [...]

.com and .net will be signed with RSASHA1 at first, only because the
planning and development for signing these zones started earlier than
the root.  While there aren't plans for an algorithm roll in .com and
.net--we want to get the zones signed first--with the root signed with
RSASHA256, rolling .com and .net to RSASHA256 is an obvious next step.


More information about the Dnssec-deployment mailing list