I answered the question that you asked. Other people are weighing in on
the root and stand by keys.
Mike
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 <mailto: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 <mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
<https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
