Re: [DNSOP] KSK rollover choices

[Michael StJohns <[e-mail]>]

On 10/31/2018 2:54 PM, Paul Vixie wrote:
>
>
> Jim Reid wrote:
>>
>>> On 31 Oct 2018, at 00:27, Mark Andrews<[e-mail]>  wrote:
>>>
>>> Bootstrap is still a issue.  Over fast TA rolling makes it more of
>>> a issue.
>>
>> Indeed. And that's the underlying problem that needs to be fixed IMO
>> - for instance when/if there's an emergency rollover.
>
> bootstrappers should have https access to a complete history of root 
> ksk, each one signed by its predecessor. this doesn't handle 
> revocation, but nothing in dnssec handles revocation, and that's by 
> design, and so i'm inclined not to worry about it.
there are at least two things wrong with the above:

1) 5011 provides revocation for ALL keys, not just the root keys, and 
that's by design.  Set the revoke bit on a key, self-sign the RRset with 
that key, and it should prevent trust being traced through the key.
2) the simple history approach will not work.  Simply consider that you 
might need to deal with compromised keys and tell me how I can ensure I 
have ALL the information I need based on a history that can actually 
reflect all types of real world input.   Something like a block chain 
(with yet another set of signatures) over a set of versions of the root 
dnskey RRSet might work, but that will require another chain of trust 
besides the dnssec chain.


>
> but that's the backup plan. the primary expectation is, devices which 
> come off the shelf after a dnssec ksk roll will have some means of 
> reaching and trusting their manufacturer's software update service, 
> which will offer them a current ksk for validation.

I think the primary expectation should really be the only plan.
>
> manufacturers who don't last long enough to do this, or who for 
> whatever other reason don't do this, will be shipping future bricks. 
> and i'm fine with that, since it's in their power to do the right 
> thing, which is the best we can offer.
>
Yup -

Mike