Re: [DNSOP] Emergency KSK Rollover for locally secure zones.

[Aanchal Malhotra <[e-mail]>]

Thanks Warren.

On Fri, Aug 4, 2017 at 4:11 PM, Warren Kumari <[e-mail]> wrote:

> On Thu, Aug 3, 2017 at 6:11 PM, Aanchal Malhotra <[e-mail]> wrote:
> >
> >
> > On Thu, Aug 3, 2017 at 11:49 PM, Michael StJohns <[e-mail]
> >
> > 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.
>

Wouldn't it be good if this document is accessible to all? Is there a
reason for this document not being public?

>
> 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.
>

That sounds like a plan (with a "significant press event" being my fav part
:))

>
> 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...
>

Yes I agree. It will be a highly unlikely and unfortunate event for the
root trust anchor to be compromised.

But what about emergency key rollover for other islands of trust/security,
if there exist any? And do we care about them?

>
> 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 <
> [e-mail]>
> >> 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
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/dnsop
> >>>
> >>
> >>
> >
> >
> > _______________________________________________
> > DNSOP mailing list
> > [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>