[ksk-rollover] alternatives to 5110 for automating roll-over

[Michael StJohns]

Inline...

On 3/29/2019 11:54 AM, Michael Richardson wrote:
> Lars-Johan Liman <liman at 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 at 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.

> 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.
No.
>
> 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 at icann.org
> https://mm.icann.org/mailman/listinfo/ksk-rollover


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ksk-rollover/attachments/20190329/7ca9755a/attachment-0001.html>