Security Considerations for RFC5011 Publishers
draft-ietf-dnsop-rfc5011-security-considerations-13

Document Type Expired Internet-Draft (dnsop WG)
Last updated 2019-01-17 (latest revision 2018-07-16)
Replaces draft-hardaker-rfc5011-security-considerations
Stream IETF
Intended RFC status Proposed Standard
Formats
Expired & archived
plain text pdf html bibtex
Stream WG state Held by WG
Document shepherd Tim Wicinski
Shepherd write-up Show (last changed 2018-07-06)
IESG IESG state Expired (IESG: Dead)
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to Tim Wicinski <tjw.ietf@gmail.com>

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at
https://www.ietf.org/archive/id/draft-ietf-dnsop-rfc5011-security-considerations-13.txt

Abstract

This document extends the RFC5011 rollover strategy with timing advice that must be followed by the publisher in order to maintain security. Specifically, this document describes the math behind the minimum time-length that a DNS zone publisher must wait before signing exclusively with recently added DNSKEYs. This document also describes the minimum time-length that a DNS zone publisher must wait after publishing a revoked DNSKEY before assuming that all active RFC5011 resolvers should have seen the revocation-marked key and removed it from their list of trust anchors. This document contains much math and complicated equations, but the summary is that the key rollover / revocation time is much longer than intuition would suggest. This document updates RFC7583 by adding an additional delays (sigExpirationTime and timingSafetyMargin). If you are not both publishing a DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new Secure Entry Point key for use as a trust anchor, you probably don't need to read this document.

Authors

Wes Hardaker (ietf@hardakers.net)
Warren Kumari (warren@kumari.net)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)