[ksk-rollover] Retention of the 2010 KSK CONSIDERED HARMFUL

[Michael StJohns]

On 4/2/2019 12:50 PM, Salz, Rich wrote:
>
>   * The problem with this is that you need to know *when* N signed
>     N+1, and you can't believe N about the time.
>
> Out of band verification. You make sure the chain you have connects 
> properly up to the current KSK.
>
Then its "Turtles all the way down". 
https://en.wikipedia.org/wiki/Turtles_all_the_way_down

At some point you've involved something outside of the DNS and you need 
a way to trust them, and a way to supercede the trust if they're 
compromised.  Or you need a crowd of them.  Etc.

I thought of time stamp services - those might work but have the same 
problem of root management  for their chain of trust - e.g. the 
resolvers need to be able to get the most recent trust anchors before 
they can validate the DNS trust anchor set....   What I'm actually 
thinking about is some form of inserting a record into the blockchain 
ledger for one of the cryptocurrencies as a mechanism for time stamping 
the state of the trust anchor set at a given point in time.  See 
references 2 and 3 of https://en.wikipedia.org/wiki/Trusted_timestamping

But that's complex and probably requires that the root key holders add 
another step to the process of managing the keys. It's not something 
that's a simple add on.


> Or you tell folks turning on old computers to just reconfig first. :)
>
That gets my vote.  Or  - they just down load all the security patches 
that have been signed with the vendor of the devices private key to 
include the new starting trust anchor set.

Later, Mike


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190402/c13a5cee/attachment.html>