Re: [dnsext] Historical root keys: The Large Router Vendor Speaks

[Thierry Moreau <[e-mail]>]

Dear John,

Some definitions and background about trust and "liability" in the 
context of root public keys (DNSSEC root KSK, open PKI root CA -- in the 
original model --, and to a lesser extent a private CA like Cisco's for 
software revisions).

An organization stands behind a root public key because it controls the 
private key counterpart. The organization announces for which purposes 
the key pair is issued, along with some cryptoperiod expectation. 
Relying parties depend on the organization internal controls of the 
private key. Some factors make the organization's responsibilities more 
demanding: the value of surreptitious access to the private key, the 
expected computing power increase in the hands of "the enemy," the wear 
and tear of continuous internal controls, and, indirectly, the size of 
the relying party population.

The cryptoperiod announcement says: after such a date, don't expect our 
internal controls to be at par with the cumulative risk exposure. It 
also says "a digital signature verification is meaningless after the end 
of the cryptperiod." More precisely, it says "don't blame us if a bogus 
digital signature floats around after the end of the cryptoperiod, we 
would have told you that the key was expired."

What you are asking for is a long cryptoperiod, either because the 
history record relied upon in 2035 uses a KSK expired in 2021, or 
because a special-purpose signature key relied upon in 2035 has entered 
IANA internal controls before 2014, the manufacturing date for Cisco boxes.

I am sure IANA does not wish to let "the world" to so rely on a long 
expired KSK without having been served this little warning "no good 
after KSK rollover which we will announce in advance." I write this from 
discussions surrounding the KSK internal controls, a time during which I 
was advocating a longer term commitment (with slightly different 
procedures) from IANA. IANA did an excellent job at this project for 
which there was no precedent, at least with an equivalent level of 
transparency. Their stubbornness (?) in making this little warning is an 
indication that their KSK operations are trustworthy *before* rollover.

For the long-term commitment from IANA for (the internal controls 
required for) a special purpose signature key, I am less certain. But if 
they do make this commitment, then WOW! "The world" would have what you 
are looking for. Bootstrap from this super-WOW signature key whenever 
you feel you need more confidence in your DNS resolution.
   - You say *only*if* the current local KSK configuration is outdated. 
I would say it's up to any gear vendor, any security officer, or any sys 
admin, in any circumstances.
   - You say it's no better than the KSK, while in fact it is: it works 
across KSK rollovers. Suppose your unit goes back on-line in 2035 and 
sees the same KSK as was current in 2014, because a bogus root is being 
operated by a hacker in the network nearby. The super-WOW signature 
verification will prevent the bogus root attack.

It's about the IANA embarrassment if something goes wrong. Semantically 
it does not turn into "liability" but that is just because secure 
electronic payments are not directly secured by DNSSEC validated RRsets 
near the top of the DNS hierarchy.

I exposed the suggested course of action for Cisco in the first e-mail 
to you (it was off-list). It is a simple selection from what you already 
identified as operationally acceptable options.

I hope it clarifies the link between long term public key crypto 
material and "trust" as the term applies to your problem statement 
(which I find very good).

Hope it helps (I wish to abstain from further contributions to the IETF 
list on this issue).

Regards,


-- 
- Thierry Moreau



John Bashinski wrote:
> On 2011-01-28 16:56, Thierry Moreau wrote:
> 
>> But once IANA (or whichever organization makes it "public") commits to
>> "it" on a long term it becomes by definition more trustworthy than the
>> root KSK.
> 
> How does that work? All validations are funneled through through the
> root KSK. Furthermore, once you're bootstrapped, all your trust anchor
> updates come as RFC 5011 signed by the root KSK. So there's no way to
> have anything more trusted than the root KSK. This is in the technical
> sense of "trusted", which is more or less equivalent to "able to spoil
> your day".
> 
> The originally proposed form of "it" was for "it" to *be* the root
> KSK. You'd start with a root KSK, and if that KSK were still in use,
> you'd be done. If not, you'd get "it" in the form of a history of root
> KSK rollovers, run through the chain, and thereafter anchor yourself at
> the current root KSK.
> 
> I still prefer that approach, but other people seem to prefer
> alternatives. Not even those the alternatives create anything that I can
> see as "more trusted" than the root. "Equally trusted" at most.
> 
>> Then suddenly the trust foundation shifts from the root KSK
>> to "it" and soon it becomes best practice to use it as the normal way
>> to bootstrap DNSSEC resolution.
> 
> Well, it certainly wouldn't be the only available way, but, yes, it
> probably would be the most common way.
> 
> What do you believe should be the "normal way"?
> 
>> Ah ah! Now "it" becomes the (default) new trust foundation. I knew it
>> would come sooner than later.
> 
> In order to enable DNSSEC by default, it MUST be possible to bootstrap
> it without human intervention, using only the information available to
> you when you first get turned on. That's what "default" means.
> 
> The current default is not to use DNSSEC at all. A tiny minority
> enables DNSSEC. That tiny minority would still be able to do whatever
> it wanted to set up trust anchors... including what it's doing today.
> 
> So what's the alternative?
> 
> 					-- jbash
>