[ksk-rollover] ICANN board meeting result and the Current status of KSK-Rollover

Warren Kumari warren at kumari.net
Fri Sep 21 23:10:55 UTC 2018

On Fri, Sep 21, 2018 at 1:21 PM Ray Bellis <ray at isc.org> wrote:

> On 21/09/2018 18:02, Michael StJohns wrote:
> > I wish people would stop repeating this stupid canard.  It's almost
> > as stupid as "IOT devices need less security".
> I should clarify.
> It's *technically* a problem with a solution, as you've outlined.
> Getting such a solution *commercially deployed* in low cost CPE seems
> somewhat harder.
> > But guidance to the CPE vendors that they need to provide firmware
> > updates for at least N years after manufacture and that those
> > firmware updates may include new root public keys seems like a good
> > document to write.
> I don't think IETF guidance alone will suffice.  It may require
> legislative mandate.

Wes Hardaker and I have a proto-draft called "Ball and Chain" - it
basically provides a chain of KSKs from the current, to the next, to the
next, to...

A resolver which has been sitting for many years can enter at whatever KSK
it knows about, and walk its way up the chain (never down) until it reaches
the current one. The keys can be annotated to provide info like "this was a
normal rollover, keep going" or "this rollover occured because of
compromise, abort, and revoke if you have already seen it". This is not
perfect - a resolver which was sleeping, and *first* awakes behind a
malicious attacker who has a copy of the private key from a compromised KSK
could be lead astray -- but, this is one of those "you need to discuss the
threat model" cases. Obviously, this can and should be used in conjunction
with things like TLS checks, etc.

I cannot remember if we actually published the draft, or were sufficiently
despondent after the last few meetings that we didn't bother....
I can find it if people are interested....


> Ray
> _______________________________________________
> ksk-rollover mailing list
> ksk-rollover at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover

I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20180921/87c1ef5d/attachment-0001.html>

More information about the ksk-rollover mailing list