Re: [DNSOP] Specification of DNSKEY "Private-key-format"

[Mukund Sivaraman <[e-mail]>]

Hi Evan

On Thu, Aug 29, 2019 at 04:11:23PM +0000, Evan Hunt wrote:
> On Thu, Aug 29, 2019 at 07:25:54PM +0530, Mukund Sivaraman wrote:
> > I am asking about where this key format is specified - I want to extend
> > it.
> 
> There's never been a written specification as far as I know, and if there
> was one, then it's definitely been obsolete since 2009, because I changed
> the format then and I didn't update any specs.
> 
> What I can tell you is: the private key file contains a format version
> string, "Private-key-format", currently always set to 1.3, and an
> algorithm string, "Algorithm".  After that comes a set of private keydata
> fields which are specific to the algorithm, and finally a set of *optional*
> metadata fields.
> 
> Those were introduced in format version 1.3. They include "Created",
> "Publish", "Delete", etc, and also a few (such as "RollPeriod") that
> were reserved for future use but we'e never gotten around to using them.
> 
> If the parser encounters any field that it doesn't recognize, and the key
> claims to be version 1.3, then it will reject the key with an error.
> However, if Private-key-format is increased to at least 1.4, then the
> version 1.3 parser will ignore the unknown fields and just use the ones
> that it does understand.  A version number above 2.0 is assumed not to be
> backward-compatible, so that key would be rejected always.

So it is a BIND-specific format. Years ago at ISC, I had looked for a
spec for it as I'd seen it used in some RFCs (e.g., RFC 6605) but could
not find one.

> We've have had a few conversations at ISC recently about adding some new
> fields and increasing the format version to 1.4, so it would probably be
> best if we coordinate our changes to ensure that your extensions are
> interoperable with ours.

For interoperability, there are other BIND-specific formats to consider
too such as the journal file format, the control channel protocol,
etc. The journal format is already incompatible between Loop and BIND,
and the control channel will soon be. I also would like for these to be
compatible and am open to collaboration.

On the topic of the private key format, there are multiple Loop tickets
that would propose changes.

* Currently, an experimental feature is being developed that needs
  additional meta fields. This caused me to ask the question.

* As you know, historically the BIND tree on unix relied on /dev/urandom
  and /dev/random (or some custom device) as sources of random
  numbers. This was slow to use, and in some environments, ran out of
  entropy. Some parts such as the dispatch code added a CSPRNG for
  source port randomization to improve performance and availablility of
  randomness. The general design led to flaws in the implementation of
  some features. Recent BIND branches appear to have tried to address
  this by switching to a mix of OpenSSL's PRNG and a local
  implementation of xoshiro128**.

  Loop is increasingly using a different crypto library, which
  implements LibreSSL portable's arc4random() based on OpenBSD's
  arc4random() and uses ChaCha with thread-local random state. It has
  replaced all usage of randomness within Loop and various hacks that
  were in place to work around randomness availability and performance
  issues have been removed. For the first time, all usage of randomness
  within the Loop tree demonstrably passes NIST SP 800-22.

  There is a ticket to implement the features of what dnssec-keymgr
  provides within named itself for ease of use of key maintenance (it is
  still named named, and will be renamed to loopd soon). This will need
  changes to metadata in the private key format, but see the next item.

* Loop has been improving how it handles key material (in memory) but
  there is still some way to go. Two aspects that I dislike about how it
  stores private keys on filesystem is that (1) they are stored in the
  clear, and (2) metadata unrelated to key material is stored alongside
  key material, though these should be in human readable form even if
  the key material is stored encrypted. This is unlike the DER->PEM form
  that OpenSSL tools generate by default (e.g., in Viktor's example).
  The key material and schedule metadata should be separated into
  different files.

Again, I'd very much like to collaborate with ISC, but the ball is in
your court.

		Mukund

--

Loop DNS nameserver: https://akira.org/loop/