On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra <aanch...@bu.edu> wrote: > > > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <m...@nthpermutation.com> > wrote: >> >> I answered the question that you asked. > > > Yes, thanks Mike. That answers my question about the attack. It was not > clear that pre-published was synonymous with stand-by keys. > >> >> Other people are weighing in on the root and stand by keys. >> >> Mike > > > However, my question (not just for Mike.) > > "If we have a solution to this (subject of this thread) problem without a > back-up key set? And do we even care about it?" still remains. >
Well, we kinda do... The plan (which I haven't seen, but have been assured exists, is well fleshed out and documented, etc) is that, if the primary is suspected to be compromised (or lost), an "emergency key roll" will occur. This involves, from what I've been told, publishing new keys / hashes on the IANA site (https://www.iana.org/dnssec/files), and a "significant press event", publishing the new key on newspapers, blogs, etc. The attestations by the trusted community reps and signatures chaining back to CA certs is supposed to prove the validity of this new key, and the compromise of the old one. Unsurprisingly, it would be good if the emergency roll process never needs to be invoked; the key protections are supposed to be safe enough that this should be very unlikely. Much of this is very similar to the loss / compromise of a CA root cert... W > Thx. >> >> >> >> >> >> On 8/3/2017 5:05 PM, Aanchal Malhotra wrote: >> >> Hi Mike, >> >> On Thu, Aug 3, 2017 at 10:47 PM, Michael StJohns <m...@nthpermutation.com> >> wrote: >>> >>> On 8/3/2017 3:01 PM, Aanchal Malhotra wrote: >>> >>> A DNSKEY RRset with pre-published KSK is signed by the old (now >>> compromised) KSK. When the resolver uses RFC 5011 for the trust anchor >>> update, the attacker can inject a new KSK (signed by the compromised KSK). >>> Which KSK is now the new Trust Anchor for the resolver? >>> >>> The resolver trust point trust anchor set contains both the old and >>> pre-published stand-by key. When the old KSK is compromised, you set the >>> revoke bit on the old KSK, and sign the DNSKEY RRSet with both the revoked >>> KSK and the standby KSK. The stand by key does not trace its trust through >>> the old key except during the process of being added. The attempt to >>> inject the new KSK is foiled by revoking the old KSK and publishing the >>> revocation before the hold-down time expires for the resolver(s). >> >> >> I understand and agree to what you say. And even RFC 5011 explicitly >> states that this approach works only if there is a >> backup/standby/pre-published (whatever name we like) and the assumption that >> both active and stand-by keys are not compromised at the same time. The >> point is again, as Warren mentioned, that one needs two trust anchors in >> this case. And the issues ensue.... Also, I am not sure if there is any >> implementations that are actually doing standby-keys (not that I am aware >> of). >> >> What I am trying to say is that we do not have a solution to this problem >> without a back-up key set? >>> >>> >>> At some point - ideally quickly after the old KSK revocation - you >>> publish a new standby KSK long enough to inject it as a new trust anchor. >>> >>> Mike >>> >>> >>> >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> >> > > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- 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 pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
