Re: [dnsext] historal root keys for upgrade path?

[Brian Dickson <[e-mail]>]

On Thu, Jan 27, 2011 at 1:49 PM, Brian Dickson
<[e-mail]> wrote:

> We complain about adoption delays. This, we should be falling over
> ourselves to assist on, or never, ever complain again about adoption.
> Seriously.

/*  *mouth = money */

Open question, to whoever feels like answering it:
Would the following, as a general mechanism for publishing someone
else's DNSKEY (securely) work?
(Here, "foreign" means, we don't hold the private keys)

(1) Using a current, known-good trust anchor, retrieve and validate
the (foreign) DNSKEY data (possibly plural).
(2) For every algorithm in the set of foreign DNSKEY data :
(2a) Generate (one time only!!!)  a new public/private key pair for
our own (local) DNSKEY
(2b) Combine the local and foreign DNSKEY data into the apex of our
own zone file, for which we are authoritative.
(2c) Sign the DNSKEYs with our private keys
(2d) RRSIGs signed by our DNSKEYs are the only RRSIGs, and there is
one for every DNSKEY algorithm present, so even "strict" validators
should be happy
(3) Provide our (permanent) public keys as trust anchors, to whoever
will use our zone as a "bootstrap" for the foreign (possibly changing)
DNSKEYs.
(4) As necessary, i.e. whenever any foreign DNSKEY needs to be
updated, added/deleted, make corresponding adds/changes to our DNSKEY
set, and re-sign the RRSET

NB - the same foreign DNSKEYs can be kept in multiple zones, so that
specific instance usage can be tracked over time.

E.g. over time, the set of algorithms required by the foreign keys may
change, and rather than continue to sign with a superset of
historically-used algorithms,  newer instances of the zone get signed
only with new local DNSKEYs for the current algorithms. Older zone
instances continue being signed with the older keys/algorithms, so
there could be a weakness related to use of them, but that would be
limited to clients with old keys, which would expect to tail off over
time (drastically, perhaps).

These zones would be used only for bootstrapping DNSKEY data used for
"real" trust anchors, and could be discarded once the "real" trust
anchor has been validated (and *only* then).

The bootstrap process would need to rely on DNSSEC-unknown
(unvalidated) data, to reach the trust-anchored zone, but the fact
that the zone is signed with the trust anchor itself, provides
"enough" security to be considered "secure", IMHO.

Brian