Lars-Johan Liman <liman@netnod.se> wrote:
ebersman> It is not the IETF's job to tell large ISP that they must do
ebersman> 5011. We need to consider that the world will never be all 5011
ebersman> and that alternate automation methods are valid and how we'd
ebersman> address that in an emergency.
mcr> I don't really understand the long-term reasons for not doing 5011.
mcr> Can you explain this further?
> list-ksk-rollover@dragon.net:
>> Phased rollout and control of when things change.
> Aye.
> I agree that we shouldn't prescribe how people automate, or even that
> they do it at all. 5011 is _one_ way to do it, and I happen to like it,
> but that doesn't mean that it is good for $everybody.
In particular, it fails when the device is not on/connected during the period
that the 5011 adds the new key, then it can not use 5011.
No - that's not correct. It fails if it wasn't able to see the
old key signing the new key for the add hold down period. If
you're following my recommendations in 5011, then the new key C is
going to be signed by A for a while, then B for a while, before it
becomes the active key.
E.g. 2 key steady state starts with A, B gets added and is signed by A for a year. Then C is added, and is signed by A (A signs the DNSKEY RRSET), then A is revoked and B signs the RRSet for another 6 months to a year. When its finally time for C to be the active key, its been signed by the other two keys for quite a long time.
The "adds the key" is a resolver state change, NOT a publisher
activity.
No.I think that an alternative to straight 5011 is needed. As far as I understand 5011, the only reason we can't leave the entire chain of keys in at the trust point is because the RRset would get unreasonably large, causing other failures.
It seems that the problem is solved if the history of the DNSkey can be placed at some other place.
5011 was designed to cause resolvers to make state changes to
their trust anchor set based on information gathered over a period
of time. No resolver makes a "add anchor" state change based on
seeing one signature - it makes it after it sees at least two
signatures over the DNSKEY RRSet over a period of time. Once the
state change is made, the "history" of the signature is
irrelevant. This important because it causes the state changes to
be tied to particular time ticks in a way that later lies can
safely be ignored.
As I said at the mike, you can't just trace the signatures, you need to trace the entire state of the trust anchor set - and that is vastly different than the contents of the DNSKEY RRSet and its associated signatures.
I've spent a lot of time thinking about this and I don't think it can be done using just information from the DNS. Basically, a key compromised at any time can rewrite the state history for any point from the time the key was valid forward. Even revoking the key doesn't help. An attacker who is able to provide the client who is trying to verify the history the attacker's version of that history can cause that client to set up its trust anchor set state the way the attacker wants it to.
Someone banned the use of the term "blockchain" in the
discussion, but something like that is probably the right
approach. BUT - blockchains like Bitcoin work because many
entities write transactions to the global block chain, and
repudiating the history to start from a previous point would be
easily detected. Given that the contents of the root key set are
being written by a single entity with a single chain of trust, I
think we're going to need mix in some other non-DNS data to gain
the same level of trust and prevent rewind of the root DNSKEY
trust anchor state.
Mike
_______________________________________________ ksk-rollover mailing list ksk-rollover@icann.org https://mm.icann.org/mailman/listinfo/ksk-rollover