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. 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 T*rust 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
