On 10/31/2018 2:54 PM, Paul Vixie wrote:
Jim Reid wrote:
On 31 Oct 2018, at 00:27, Mark Andrews<[email protected]> 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
