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

[Michael StJohns]

On 4/2/2019 1:27 PM, Michael StJohns wrote:
> 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
>
OK - here's what I came up with:

H[0] = 32'0' (32 bytes of 0).

Once a (day | week), generate  H[N] = HASH(H[N-1] || root DNSKEY RRSet 
encoded in canonical order || root RRSIG(DNSKEY) RRSet encoded in 
canonical order || date stamp)

Using something like https://originstamp.org/home, submit H[N] to the 
block chain ledger.

Retain a record of each submission including the origin data, hash, 
block chain record, and date stamp of submission.

Recovery is:

1) Get a copy of the list of states (contents of the RRSig and DNSKEY 
record sets) between the last time I was live and now.

2) Verify that they are sequenced properly and that the calculated 
hashes match up with the contents of the block chain ledger.

3) Run the records in order through a psuedo-5011 update scheme (e.g. 
process the records as if you'd retrieved them at the time of the ledger 
submission - basically running your 5011 clocks driven by the blockchain 
submission).  Verify any signatures and mark the keys revoked or added 
as you would as if you'd gotten them at the time of ledger submission.

4) Fail the process if any verification step fails - fail over to manual 
update.

Notes:

1) No less often than a week - any longer and its possible you can have 
events that happen that are removed from the state before the ledger 
entry is made.  The actual number should be based on some fractional 
multiple of the minimums of the TTL and the signature durations.

2) Useful to have third party verification that the ledger is tracking 
the state as provided by the root publisher.

3) Because the time of submission is locked in place relative to a lot 
of other transactions, it should be impossible for a revoked key to 
later lie in a way that causes a resolver to accept that lie.  E.g. 
signing a key add RRSet in 2025 that purports to add a fake key in 2020 
(i.e. the signature date times in the RRSig are 2020 even though the 
signature is being formed in 2025).

4) At 1 record a week, this is about a 100 records to parse and process 
if you're dormant for 2 years.  And NO - you may not accept the last 
transaction in the ledger as the final state of the trust anchor set.  
You MUST process all of the transactions in order.

5) None of this requires the additional use of any of the private key 
material (besides it being used at the time it signs the DNSKEY RRSet).  
So delete the 2010 key.

This is more complex than "just sign the key", but it also probably 
works unlike "just sign the key".

Mike


> 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/20190404/cdee7686/attachment-0001.html>