Network Working Group                                         M. StJohns
Internet-Draft                                             Nominum, Inc.
Expires: April 14, 2005                                 October 14, 2004

                Automated Updates of DNSSEC Trust Anchors

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
    author represents that any applicable patent or other IPR claims of
    which he or she is aware have been or will be disclosed, and any of
    which he or she become aware will be disclosed, in accordance with
    RFC 3668.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    The list of current Internet-Drafts can be accessed at

    The list of Internet-Draft Shadow Directories can be accessed at

    This Internet-Draft will expire on April 14, 2005.

Copyright Notice

    Copyright (C) The Internet Society (2004).


    This document describes a means for automated, authenticated and
    authorized updating of DNSSEC "trust anchors".  The method provides
    protection against single key compromise of a key in the trust point
    key set.  Based on the trust established by the presence of a current
    anchor, other anchors may be added at the same place in the
    hierarchy, and, ultimately, supplant the existing anchor.

    This mechanism, if adopted, will require changes to resolver

StJohns                  Expires April 14, 2005                 [Page 1]

Internet-Draft             trustanchor-update               October 2004

    management behavior (but not resolver resolution behavior), and the
    addition of a single flag bit to the DNSKEY record.

Table of Contents

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
      1.1   Compliance Nomenclature  . . . . . . . . . . . . . . . . .  3
      1.2   Changes since -00  . . . . . . . . . . . . . . . . . . . .  3
    2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  4
      2.1   Revocation . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.2   Add Hold-Down  . . . . . . . . . . . . . . . . . . . . . .  5
      2.3   Remove Hold-down . . . . . . . . . . . . . . . . . . . . .  5
      2.4   Active Refresh . . . . . . . . . . . . . . . . . . . . . .  6
      2.5   Resolver Parameters  . . . . . . . . . . . . . . . . . . .  6
        2.5.1   Add Hold-Down Time . . . . . . . . . . . . . . . . . .  6
        2.5.2   Remove Hold-Down Time  . . . . . . . . . . . . . . . .  6
        2.5.3   Minimum Trust Anchors per Trust Point  . . . . . . . .  6
    3.  Changes to DNSKEY RDATA Wire Format  . . . . . . . . . . . . .  6
    4.  State Table  . . . . . . . . . . . . . . . . . . . . . . . . .  6
      4.1   Events . . . . . . . . . . . . . . . . . . . . . . . . . .  7
      4.2   States . . . . . . . . . . . . . . . . . . . . . . . . . .  7
    5.  Scenarios  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
      5.1   Adding A Trust Anchor  . . . . . . . . . . . . . . . . . .  8
      5.2   Deleting a Trust Anchor  . . . . . . . . . . . . . . . . .  9
      5.3   Key Roll-Over  . . . . . . . . . . . . . . . . . . . . . .  9
      5.4   Active Key Compromised . . . . . . . . . . . . . . . . . .  9
      5.5   Stand-by Key Compromised . . . . . . . . . . . . . . . . .  9
    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
      6.1   Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
      6.2   Multiple Key Compromise  . . . . . . . . . . . . . . . . . 10
      6.3   Dynamic Updates  . . . . . . . . . . . . . . . . . . . . . 10
    7.  Normative References . . . . . . . . . . . . . . . . . . . . . 10
        Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
        Intellectual Property and Copyright Statements . . . . . . . . 12

StJohns                  Expires April 14, 2005                 [Page 2]

Internet-Draft             trustanchor-update               October 2004

1.  Introduction

    As part of the reality of fielding DNSSEC (Domain Name System
    Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community
    has come to the realization that there will not be one signed name
    space, but rather islands of signed name space each originating from
    specific points (i.e.  'trust points') in the DNS tree.  Each of
    those islands will be identified by the trust point name, and
    validated by at least one associated public key.  For the purpose of
    this document we'll call the association of that name and a
    particular key a 'trust anchor'.  A particular trust point can have
    more than one key designated as a trust anchor.

    For a DNSSEC-aware resolver to validate information in a DNSSEC
    protected branch of the hierarchy, it must have knowledge of a trust
    anchor applicable to that branch.  It may also have more than one
    trust anchor for any given trust point.  Under current rules, a chain
    of trust for DNSSEC-protected data that chains its way back to ANY
    known trust anchor is considered 'secure'.

    Because of the probable balkanization of the DNSSEC tree due to
    signing voids at key locations, a resolver may need to know literally
    thousands of trust anchors to perform its duties.  (e.g.  Consider an
    unsigned ".COM".) Requiring the owner of the resolver to manually
    manage this many relationships is problematic.  It's even more
    problematic when considering the eventual requirement for key
    replacement/update for a given trust anchor.  The mechanism described
    herein won't help with the initial configuration of the trust anchors
    in the resolvers, but should make trust point key
    replacement/rollover more viable.

    As mentioned above, this document describes a mechanism whereby a
    resolver can update the trust anchors for a given trust point, mainly
    without human intervention at the resolver.  There are some corner
    cases discussed (e.g.  multiple key compromise) that may require
    manual intervention, but they should be few and far between.  This
    document DOES NOT discuss the general problem of the initial
    configuration of trust anchors for the resolver.

1.1  Compliance Nomenclature

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    document are to be interpreted as described in BCP 14, [RFC2119].

1.2  Changes since -00

    Resubmitted draft-stjohns-dnssec-trustupdate as a working group

StJohns                  Expires April 14, 2005                 [Page 3]

Internet-Draft             trustanchor-update               October 2004


    Added the concept of timer triggered resolver queries to refresh the
    resolvers view of the trust anchor key RRSet.

2.  Theory of Operation

    The general concept of this mechanism is that existing trust anchors
    can be used to authenticate new trust anchors at the same point in
    the DNS hierarchy.  When a new SEP key is added to a trust point
    DNSKEY RRSet, and when that RRSet is validated by an existing trust
    anchor, then the new key can be added to the set of trust anchors.

    There are some issues with this approach which need to be mitigated.
    For example, a compromise of one of the existing keys could allow an
    attacker to add their own 'valid' data.  This implies a need for a
    method to revoke an existing key regardless of whether or not that
    key is compromised.  As another example assuming a single key
    compromise, an attacker could add a new key and revoke all the other
    old keys.

2.1  Revocation

    Assume two trust anchor keys A and B.  Assume that B has been
    compromised.  Without a specific revocation bit, B could invalidate A
    simply by sending out a signed trust point key set which didn't
    contain A.  To fix this, we add a mechanism which requires knowledge
    of the private key of a DNSKEY to revoke that DNSKEY.

    A key is considered revoked when the resolver sees the key in a
    self-signed RRSet and the key has the REVOKE bit set to '1'.  Once
    the resolver sees the REVOKE bit, it MUST NOT use this key as a trust
    anchor or for any other purposes except validating the RRSIG over the
    DNSKEY RRSet specifically for the purpose of validating the
    revocation.  Unlike the 'Add' operation below, revocation is
    immediate and permanent upon receipt of a valid revocation at the

    N.B.  A DNSKEY with the REVOKE bit set has a different fingerprint
    than one without the bit set.  This affects the matching of a DNSKEY
    to DS records in the parent, or the fingerprint stored at a resolver
    used to configure a trust point.  [msj3]

    In the given example, the attacker could revoke B because it has
    knowledge of B's private key, but could not revoke A.

StJohns                  Expires April 14, 2005                 [Page 4]

Internet-Draft             trustanchor-update               October 2004

2.2  Add Hold-Down

    Assume two trust point keys A and B.  Assume that B has been
    compromised.  An attacker could generate and add a new trust anchor
    key - C (by adding C to the DNSKEY RRSet and signing it with B), and
    then invalidate the compromised key.  This would result in the both
    the attacker and owner being able to sign data in the zone and have
    it accepted as valid by resolvers.

    To mitigate, but not completely solve, this problem, we add a
    hold-down time to the addition of the trust anchor.  When the
    resolver sees a new SEP key in a validated trust point DNSKEY RRSet,
    the resolver starts an acceptance timer, and remembers all the keys
    that validated the RRSet.  If the resolver ever sees the DNSKEY RRSet
    without the new key but validly signed, it stops the acceptance
    process and resets the acceptance timer.  If all of the keys which
    were originally used to validate this key are revoked prior to the
    timer expiring, the resolver stops the acceptance process and resets
    the timer.

    Once the timer expires, the new key will be added as a trust anchor
    the next time the validated RRSet with the new key is seen at the
    resolver.  The resolver MUST NOT treat the new key as a trust anchor
    until the hold down time expires AND it has retrieved and validated a
    DNSKEY RRSet after the hold down time which contains the new key.

    N.B.: Once the resolver has accepted a key as a trust anchor, the key
    MUST be considered a valid trust anchor by that resolver until
    explictly revoked as described above.

    In the given example, the zone owner can recover from a compromise by
    revoking B and adding a new key D and signing the DNSKEY RRSet with
    both A and B.

    The reason this does not completely solve the problem has to do with
    the distributed nature of DNS.  The resolver only knows what it sees.
    A determined attacker who holds one compromised key could keep a
    single resolver from realizing that key had been compromised by
    intercepting 'real' data from the originating zone and substituting
    their own (e.g.  using the example, signed only by B).  This is no
    worse than the current situation assuming a compromised key.

2.3  Remove Hold-down

    A new key which has been seen by the resolver, but hasn't reached
    it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
    zone owner.  If the resolver sees a validated DNSKEY RRSet without
    this key, it waits for the remove hold-down time and then, if the key

StJohns                  Expires April 14, 2005                 [Page 5]

Internet-Draft             trustanchor-update               October 2004

    hasn't reappeared, SHOULD discard any information about the key.

2.4  Active Refresh

    A resolver which has been configured for automatic update of keys
    from a particular trust point MUST query that trust point (e.g.  do a
    lookup for the DNSKEY RRSet and related RRSIG records) no less often
    than the lesser of 15 days or half the original TTL for the DNSKEY
    RRSet or half the RRSIG expiration interval.  The expiration interval
    is the amount of time from when the RRSIG was last retrieved until
    the expiration time in the RRSIG.

    If the query fails, the resolver MUST repeat the query until
    satisfied no more often than once an hour and no less often than the
    lesser of 1 day or 10% of the original TTL or 10% of the original
    expiration interval.

2.5  Resolver Parameters

2.5.1  Add Hold-Down Time

    The add hold-down time is 30 days or the expiration time of the TTL
    of the first trust point DNSKEY RRSet which contained the key,
    whichever is greater.  This ensures that at least two validated
    DNSKEY RRSets which contain the new key MUST be seen by the resolver
    prior to the key's acceptance.

2.5.2  Remove Hold-Down Time

    The remove hold-down time is 30 days.

2.5.3  Minimum Trust Anchors per Trust Point

    A compliant resolver MUST be able to manage at least five SEP keys
    per trust point.

3.  Changes to DNSKEY RDATA Wire Format

    Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
    flag.  If this bit is set to '1', AND the resolver sees an
    RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
    consider this key permanently invalid for all purposes except for
    validing the revocation.

4.  State Table

    The most important thing to understand is the resolver's view of any
    key at a trust point.  The following state table describes that view

StJohns                  Expires April 14, 2005                 [Page 6]

Internet-Draft             trustanchor-update               October 2004

    at various points in the key's lifetime.  The table is a normative
    part of this specification.  The initial state of the key is 'Start'.
    The resolver's view of the state of the key changes as various events

    [msj1] This is the state of a trust point key as seen from the
    resolver.  The column on the left indicates the current state.  The
    header at the top shows the next state.  The intersection of the two
    shows the event that will cause the state to transition from the
    current state to the next.

                              NEXT STATE
     FROM   |Start  |AddPend |Valid  |Missing|Revoked|Removed|
    Start   |       |NewKey  |       |      |       |      |
    AddPend |KeyRem |        |AddTime|       |       |
    Valid   |       |        |       |KeyRem |Revbit |       |
    Missing |       |        |KeyPres|       |Revbit |       |
    Revoked |       |        |       |      |       |RemTime|
    Removed |       |        |       |      |       |      |

4.1  Events
    NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
       That key will become a new trust anchor for the named trust point
       after its been present in the RRSet for at least 'add time'.
    KeyPres The key has returned to the valid DNSKEY RRSet.
    KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
       this key.
    AddTime The key has been in every valid DNSKEY RRSet seen for at
       least the 'add time'.
    RemTime A revoked key has been missing from the trust point DNSKEY
       RRSet for sufficient time to be removed from the trust set.
    RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
       "REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
       signed by this key.

4.2  States

StJohns                  Expires April 14, 2005                 [Page 7]

Internet-Draft             trustanchor-update               October 2004

    Start The key doesn't yet exist as a trust anchor at the resolver.
       It may or may not exist at the zone server, but hasn't yet been
       seen at the resolver.
    AddPend The key has been seen at the resolver, has its 'SEP' bit set,
       and has been included in a validated DNSKEY RRSet.  There is a
       hold-down time for the key before it can be used as a trust
    Valid The key has been seen at the resolver and has been included in
       all validated DNSKEY RRSets from the time it was first seen up
       through the hold-down time.  It is now valid for verifying RRSets
       that arrive after the hold down time.  Clarification:  The DNSKEY
       RRSet does not need to be continuously present at the resolver
       (e.g.  its TTL might expire).  If the RRSet is seen, and is
       validated (i.e.  verifies against an existing trust anchor), this
       key MUST be in the RRSet otherwise  a 'KeyRem' event is triggered.
    Missing This is an abnormal state.  The key remains as a valid trust
       point key, but was not seen at the resolver in the last validated
       DNSKEY RRSet.  This is an abnormal state because the zone operator
       should be using the REVOKE bit prior to removal.  [Discussion
       item:  Should a missing key be considered revoked after some
       period of time?]
    Revoked This is the state a key moves to once the resolver sees an
       RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
       this key with its REVOKE bit set to '1'.  Once in this state, this
       key MUST permanently be considered invalid as a trust anchor.
    Removed After a fairly long hold-down time, information about this
       key may be purged from the resolver.  A key in the removed state
       MUST NOT be considered a valid trust anchor.

5.  Scenarios

    The suggested model for operation is to have one active key and one
    stand-by key at each trust point.  The active key will be used to
    sign the DNSKEY RRSet.  The stand-by key will not normally sign this
    RRSet, but the resolver will accept it as a trust anchor if/when it
    sees the signature on the trust point DNSKEY RRSet.

    Since the stand-by key is not in active signing use, the associated
    private key may (and SHOULD) be provided with additional protections
    not normally available to a key that must be used frequently.  E.g.
    locked in a safe, split among many parties, etc.  Notionally, the
    stand-by key should be less subject to compromise than an active key,
    but that will be dependent on operational concerns not addressed

5.1  Adding A Trust Anchor

    Assume an existing trust anchor key 'A'.

StJohns                  Expires April 14, 2005                 [Page 8]

Internet-Draft             trustanchor-update               October 2004

    1.  Generate a new key pair.
    2.  Create a DNSKEY record from the key pair and set the SEP and Zone
        Key  bits.
    3.  Add the DNSKEY to the RRSet.
    4.  Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
    5.  Wait a while.

5.2  Deleting a Trust Anchor

    Assume existing trust anchors 'A' and 'B' and that you want to revoke
    and delete 'A'.
    1.  Set the revolcation bit on key 'A'.
    2.  Sign the DNSKEY RRSet with both 'A' and 'B'.
    'A' is now revoked.  The operator SHOULD include the revoked 'A' in
    the RRSet for at least the remove hold-down time, but then may remove
    it from the DNSKEY RRSet.

5.3  Key Roll-Over

    Assume existing keys A and B.  'A' is actively in use (i.e.  has been
    signing the DNSKEY RRSet.)  'B' was the stand-by key.  (i.e.  has
    been in the DNSKEY RRSet and is a valid trust anchor, but wasn't
    being used to sign the RRSet.)
    1.  Generate a new key pair 'C'.
    2.  Add 'C' to the DNSKEY RRSet.
    3.  Set the revocation bit on key 'A'.
    4.  Sign the RRSet with 'A' and 'B'.
    'A' is now revoked, 'B' is now the active key, and 'C' will be  the
    stand-by key once the hold-down expires.  The operator SHOULD include
    the revoked 'A' in the RRSet for at least the remove hold-down time,
    but may then remove it from the DNSKEY RRSet.

5.4  Active Key Compromised

    This is the same as the mechanism for Key Roll-Over (Section 5.3)
    above assuming 'A' is the active key.

5.5  Stand-by Key Compromised

    Using the same assumptions and naming conventions as Key Roll-Over
    (Section 5.3) above:
    1.  Generate a new key pair 'C'.
    2.  Add 'C' to the DNSKEY RRSet.
    3.  Set the revocation bit on key 'B'.
    4.  Sign the RRSet with 'A' and 'B'.
    'B' is now revoked, 'A' remains the active key, and 'C' will be the
    stand-by key once the hold-down expires.  'B' SHOULD continue to be

StJohns                  Expires April 14, 2005                 [Page 9]

Internet-Draft             trustanchor-update               October 2004

    included in the RRSet for the remove hold-down time.

6.  Security Considerations

6.1  Key Ownership vs Acceptance Policy

    The reader should note that, while the zone owner is responsible
    creating and distributing keys, it's wholly the decision of the
    resolver owner as to whether to accept such keys for the
    authentication of the zone information.  This implies the decision
    update trust anchor keys based on trust for a current trust anchor
    key is also the resolver owner's decision.

    The resolver owner (and resolver implementers) MAY choose to permit
    or prevent key status updates based on this mechanism for specific
    trust points.  If they choose to prevent the automated updates, they
    will need to establish a mechanism for manual or other out-of-band
    updates outside the scope of this document.

6.2  Multiple Key Compromise

    This scheme permits recovery as long as at least one valid trust
    anchor key remains uncompromised.  E.g.  if there are three keys, you
    can recover if two of them are compromised.  The zone owner should
    determine their own level of comfort with respect to the number of
    active valid trust anchors in a zone and should be prepared to
    implement recovery procedures once they detect a compromise.  A
    manual or other out-of-band update of all resolvers will be required
    if all trust anchor keys at a trust point are compromised.

6.3  Dynamic Updates

    Allowing a resolver to update its trust anchor set based in-band key
    information is potentially less secure than a manual process.
    However, given the nature of the DNS, the number of resolvers that
    would require update if a trust anchor key were compromised, and the
    lack of a standard management framework for DNS, this approach is no
    worse than the existing situation.

7  Normative References

    [DSINTRO]  Arends, R., "DNS Security Introduction and Requirements",
               ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004,

    [DSPROT]   Arends, R., "Protocol Modifications for the DNS Security
               Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt,

StJohns                  Expires April 14, 2005                [Page 10]

Internet-Draft             trustanchor-update               October 2004

               October 2004,

    [DSREC]    Arends, R., "Resource Records for the DNS Security
               Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt,
               October 2004,

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

Editorial Comments

    [msj1]  msj: N.B. This table is preliminary and will be revised to
            match implementation experience.  For example, should there
            be a state for "Add hold-down expired, but haven't seen the
            new RRSet"?

    [msj2]  msj: To be assigned.

    [msj3]  msj: For discussion: What's the implementation guidance for
            resolvers currently with respect to the non-assigned flag
            bits?  If they consider the flag bit when doing key matching
            at the trust anchor, they won't be able to match.

Author's Address

    Michael StJohns
    Nominum, Inc.
    2385 Bay Road
    Redwood City, CA  94063

    Phone: +1-301-528-4729

StJohns                  Expires April 14, 2005                [Page 11]

Internet-Draft             trustanchor-update               October 2004

Intellectual Property Statement

    The IETF takes no position regarding the validity or scope of any
    Intellectual Property Rights or other rights that might be claimed to
    pertain to the implementation or use of the technology described in
    this document or the extent to which any license under such rights
    might or might not be available; nor does it represent that it has
    made any independent effort to identify any such rights.  Information
    on the procedures with respect to rights in RFC documents can be
    found in BCP 78 and BCP 79.

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the use of
    such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at

    The IETF invites any interested party to bring to its attention any
    copyrights, patents or patent applications, or other proprietary
    rights that may cover technology that may be required to implement
    this standard.  Please address the information to the IETF at

    The IETF has been notified of intellectual property rights claimed in
    regard to some or all of the specification contained in this
    document.  For more information consult the online list of claimed

Disclaimer of Validity

    This document and the information contained herein are provided on an

Copyright Statement

    Copyright (C) The Internet Society (2004).  This document is subject
    to the rights, licenses and restrictions contained in BCP 78, and
    except as set forth therein, the authors retain all their rights.

StJohns                  Expires April 14, 2005                [Page 12]

Internet-Draft             trustanchor-update               October 2004


    Funding for the RFC Editor function is currently provided by the
    Internet Society.

StJohns                  Expires April 14, 2005                [Page 13]