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

[Thierry Moreau <[e-mail]>]

David Conrad wrote:
> On Jan 26, 2011, at 1:26 PM, Joe Abley wrote:
>> Wouter's earlier proposal which is mentioned elsewhere in this thread had the principle defect that its use relied upon trusting signatures made by old keys, which in general some of us thought was a poor idea (e.g. in the event that a key was rolled because it was compromised).
> 
> I don't think that's a risk. If a key is rolled because of a known compromise, it simply means you can't safely chain from the old-but-installed-key to the current-but-not-yet-installed key.  Presumably, when a key is known to be compromised, the chain from old to current keys would be broken such that automated systems would require human intervention.
>

A known compromise might occur at T[n]-epsilon but detected at 
T[n]+delta (T[n] is the absolute time of rollover, and epsilon is less 
than previous cryptoperiod, i.e. T[n]-T[n-1]). Then, human intervention 
is pointless for systems that has been on-line (too late to do anything) 
and very much unlikely for those having been off-line during these 
troubled times.

Note that RFC5011 could have been "practiced" (by who would you guess 
... IANA) such that the next KSK is pre-announced at T[n-1]+mu (mu is 
small). If mu+epsilon<T[n]-T[n-1], then the on-line systems would 
reliably recover at T[n] without an implicit leap-of-faith. But that 
path would have made the root DNSKEY RRset larger.

(I quoted "practiced" because RFC5011 mandates specific validator 
procedures and allows various strategies for the root/island-of-trust 
zone manager.)

> As far as I can tell the real risk is that an attacker has an increased amount of time to secretly compromise any key in the old to current chain, thereby enabling a MITM attack to insert a branch to a new chain that will end in a malicious key.  The continued use of the old keys for something valuable means the keys have to be much stronger and it sort of defeats the purpose of scheduled rolling of keys.
> 

Correct, that is a risk or concern.

As a more general observation, what is needed here, in essence, is a 
small assistance (sign current root KSK) from a public-key based 
notarization service (the foremost example of a PK scheme with long-term 
trust at the core of the mission statement).

However, neither IETF standardization activities nor organizations 
involved in the DNS root operations ever considered the PK notarization 
seriously.

Hence my general conclusion that DNSSEC validation must rely on some 
leap-of-faith somehow somewhere, like it or not. Root KSK recovery may 
require leap-of-faith. Unless the whole DNSSEC root zone management is 
revisited, which is not going to occur.

Some may not like the color of the room where the leap-of-faith occurs 
(yes, I did watch portions of the ICANN-staged ceremonies, thanks for 
the webcast, but no, I don't recall the color of the room). If there is 
more to it, the requirements should be spelled out in terms of basic 
deployment strategies for public key capabilities.

Regards,

-- 
- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1

Tel. [phone]