<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Sep 21, 2018 at 1:21 PM Ray Bellis <<a href="mailto:ray@isc.org">ray@isc.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 21/09/2018 18:02, Michael StJohns wrote:<br>
<br>
> I wish people would stop repeating this stupid canard.  It's almost<br>
> as stupid as "IOT devices need less security".<br>
<br>
I should clarify.<br>
<br>
It's *technically* a problem with a solution, as you've outlined.<br>
<br>
Getting such a solution *commercially deployed* in low cost CPE seems<br>
somewhat harder.<br>
<br>
> But guidance to the CPE vendors that they need to provide firmware<br>
> updates for at least N years after manufacture and that those<br>
> firmware updates may include new root public keys seems like a good<br>
> document to write.<br>
<br>
I don't think IETF guidance alone will suffice.  It may require<br>
legislative mandate.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">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...</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">I cannot remember if we actually published the draft, or were sufficiently despondent after the last few meetings that we didn't bother....</div><div class="gmail_default" style="font-family:verdana,sans-serif">I can find it if people are interested....</div><br></div><div><br></div><div><div class="gmail_default" style="font-family:verdana,sans-serif">W</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Ray<br>
_______________________________________________<br>
ksk-rollover mailing list<br>
<a href="mailto:ksk-rollover@icann.org" target="_blank">ksk-rollover@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ksk-rollover" rel="noreferrer" target="_blank">https://mm.icann.org/mailman/listinfo/ksk-rollover</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">I don't think the execution is relevant when it was obviously a bad idea in the first place.<br>This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.<br>   ---maf</div></div>