I did a quick review - it's improving, but still is getting the basics
wrong.
This document is written with language that works only with the start
with one key/one key in/one key out/end with one key model for trust
anchor keys. 5011 specifically recommends that there be at least two
trust anchor keys and this document doesn't quite get the problem
statement right given that both 5011 and DNSSEC support a steady state
of more than one trust anchor key.
The actual issues related to the problem stated (of publisher guidance)
are "How long must a publisher wait after publishing a new key before
revoking ALL previous trust anchors?" And "How long to wait before
signing ONLY with the newest key?" (These are actually the same
question looked at from slightly different angles). The issue is not the
more limited generic question of how long to wait before you start
signing with the new key. (Please avoid the phrasing "use the key"
throughout).
For example, consider a trust point with trust anchor keys A, B and
where A is generally signing the DNSKEY RR Set at the trust point. The
publisher desires to replace A with a new key C. The publisher
generates C, signs the RRSet with B and publishes the RRSet containing B
and C. At time T+holddown, C has probably joined the first of many
validator trust point sets. At some time T+holddown+N, most of the live
validators will have added C. At this point the publisher revokes A,
publishes a trust set with A, B, C and signed with A and B and continues
this for at least the hold down time. At which point the published
RRSet is now B, C signed by B (C is a standby key) and most validators
trust points have B,C installed in them. (Or B signed by B for that
matter - "Missing" is an abnormal state, not an illegal one and was
there mainly because RRSet size issues mostly weren't brought up while
5011 was being discussed).
Note that A could have been revoked starting with the first publication
of C at the cost of reducing the validator trust anchor set to a single
key. That would be the model for an emergency revocation of A.
So: Minimum time to start signing with the new key is the hold down
time (you can sign earlier, but no validator will trace trust through it
so why bother?).
Minimum time to wait before revoking all previous trust anchors OR
signing the RRSet ONLY with the new key is hold down time counted from
expiration date of the signature over previous DNSKey RRSET plus some
slop - in the example the slop is 7 days and that's a reasonable value
for the parameters. That's also the minimum time a new key should be
published and signed even if you're planning on using it as a backup key
and not including it in further RRSets for now.
Note that the example in the draft at section 6 is missing a
consideration. It's not the expiration time, but the expiration date
that needs to be considered - if you issue a new RRSet while the
signature on the old one has only 4 days to go, you have the 4 day
exposure, not 10.
Mike
On 5/24/2017 1:40 AM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.
Title : Security Considerations for RFC5011 Publishers
Authors : Wes Hardaker
Warren Kumari
Filename :
draft-ietf-dnsop-rfc5011-security-considerations-01.txt
Pages : 12
Date : 2017-05-23
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
