RFC 5011

RFC 5011: Automated Updates of DNS Security (DNSSEC) Trust Anchors 🎀

Okay bestie, so this one is by M. StJohns, who wrote it as an Independent author (not through a working group) 💅. It's on the Standards Track and dated September 2007. It belongs to the Network Working Group series as Request for Comments: 5011. The title block doesn't list any documents it obsoletes or updates, so it stands on its own ✨.

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.

Abstract 🦋

Okay, so this doc describes a way to automatically, authenticated-ly, and authorized-ly update DNSSEC "trust anchors" 🔐. The method protects against N-1 key compromises of N keys in the trust point key set, which is so iconic. Based on the trust that comes from a current anchor, other anchors can be added at the same place in the hierarchy and eventually replace the existing anchor(s) 🔄.

This mechanism needs changes to resolver management behavior (but NOT to resolver resolution behavior), plus one new flag bit in the DNSKEY record 🧚.

Table of Contents 🗂️

   1. Introduction ....................................................2
      1.1. Compliance Nomenclature ....................................3
   2. Theory of Operation .............................................3
      2.1. Revocation .................................................4
      2.2. Add Hold-Down ..............................................4
      2.3. Active Refresh .............................................5
      2.4. Resolver Parameters ........................................6
           2.4.1. Add Hold-Down Time ..................................6
           2.4.2. Remove Hold-Down Time ...............................6
           2.4.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. Trust Point Deletion ............................................8
   6. Scenarios - Informative .........................................9
      6.1. Adding a Trust Anchor ......................................9
      6.2. Deleting a Trust Anchor ....................................9
      6.3. Key Roll-Over .............................................10
      6.4. Active Key Compromised ....................................10
      6.5. Stand-by Key Compromised ..................................10
      6.6. Trust Point Deletion ......................................10
   7. IANA Considerations ............................................11
   8. Security Considerations ........................................11
      8.1. Key Ownership vs. Acceptance Policy .......................11
      8.2. Multiple Key Compromise ...................................12
      8.3. Dynamic Updates ...........................................12
   9. Normative References ...........................................12
   10. Informative References ........................................12

1. Introduction ✨

Okay so, as part of actually deploying DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] [RFC4035], the community has realized there won't be one single signed name space. Instead there will be islands of signed name spaces, each starting from specific points (i.e., 'trust points') in the DNS tree 🏝️. Each island is identified by its trust point name and validated by at least one associated public key. In this document we call the pairing of that name and a particular key a 'trust anchor' 💖. A single 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 know about a trust anchor that applies to that branch. It MAY also have more than one trust anchor for any given trust point. Under the current rules, a chain of trust for DNSSEC-protected data that leads back to ANY known trust anchor is considered 'secure' 🔒.

Because the DNSSEC tree will probably get balkanized by signing voids at key locations, a resolver may need to know literally thousands of trust anchors to do its job (think about an unsigned ".COM", for example) 😭. Making the resolver owner manage all these relationships by hand is a huge problem. It's even more of a problem once you think about eventually needing to replace or update the key for a given trust anchor. The mechanism in this doc won't help with the initial configuration of trust anchors in resolvers, but it should make trust point key replacement/rollover way more viable 🙌.

So yeah, this doc describes a mechanism where a resolver can update the trust anchors for a given trust point, mostly without a human touching the resolver 🤖. A few corner cases (e.g., multiple key compromise) are discussed, and those may need manual intervention, but they should be few and far between 🌈. This document DOES NOT discuss the general problem of initial configuration of trust anchors for the resolver.

1.1. Compliance Nomenclature 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC2119].

2. Theory of Operation 🧠

The core idea here is that existing trust anchors can be used to authenticate new trust anchors at the same point in the DNS hierarchy 🔑. When a zone operator adds a new SEP key (i.e., a DNSKEY with the Secure Entry Point bit set) (see [RFC4034], Section 2.1.1) to a trust point DNSKEY RRSet, and that RRSet is validated by an existing trust anchor, then the resolver can add the new key to its set of valid trust anchors for that trust point ✅.

This approach has some issues that need mitigating 😬. For example, if an attacker compromises one of the existing keys, they could add their own 'valid' data. That means we need a way to revoke an existing key whether or not it's compromised. Another example: assuming a single key compromise, we need to stop an attacker from adding a new key and revoking all the other old keys 🚫.

2.1. Revocation 💀

Let's say we have two trust anchor keys, A and B, and B has been compromised. Without a specific revocation bit, B could invalidate A just by sending out a signed trust point key set that doesn't contain A 😱. To fix that, we add a mechanism that requires knowing the private key of a DNSKEY in order 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 (see Section 7 below) set to '1'. Once the resolver sees the REVOKE bit, it MUST NOT use this key as a trust anchor or for any other purpose, except to validate the RRSIG that signed the DNSKEY RRSet specifically for the purpose of validating the revocation. Unlike the 'Add' operation below, revocation is immediate and permanent once a valid revocation reaches the resolver 🚨.

A self-signed RRSet is a DNSKEY RRSet that contains the specific DNSKEY and has a corresponding validated RRSIG record. It's not a special kind of DNSKEY RRSet, just a way of describing the validation requirements for that RRSet 📝.

N.B.: A DNSKEY with the REVOKE bit set has a different fingerprint than one without the bit set. This affects how a DNSKEY matches DS records in the parent [RFC3755], and also the fingerprint stored at a resolver used to configure a trust point 👀.

In the example above, the attacker could revoke B because they know B's private key, but they could not revoke A 🙅‍♀️.

2.2. Add Hold-Down ⏳

Let's say we have two trust point keys, A and B, and 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. That would mean both the attacker and the owner could sign data in the zone and have it accepted as valid by resolvers 😭🙈.

To reduce this problem (though not completely solve it), we add a hold-down time to the addition of a trust anchor 🛡️. When the resolver sees a new SEP key in a validated trust point DNSKEY RRSet, it 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 for that key and resets the acceptance timer. If all of the keys originally used to validate this key are revoked before the timer expires, the resolver stops the acceptance process and resets the timer.

Once the timer expires, the new key is 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, received after the hold-down time, that contains the new key 🚦.

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

In the example above, the zone owner can recover from a compromise by revoking B, then adding a new key D and signing the DNSKEY RRSet with both A and B 🦸‍♀️.

This doesn't completely solve the problem, and that's because of 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 ever realizing the key was 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 when a key is assumed compromised.

2.3. Active Refresh 🔄

A resolver that has been configured for automatic key updates 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, half the original TTL for the DNSKEY RRSet, or half the RRSIG expiration interval, and no more often than once per hour ⏰. The expiration interval is the amount of time from when the RRSIG was last retrieved until the expiration time in the RRSIG. So the formula is:

queryInterval = MAX(1 hr, MIN (15 days, 1/2*OrigTTL,
1/2*RRSigExpirationInterval))

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

retryTime = MAX (1 hour, MIN (1 day,
.1 * origTTL, .1 * expireInterval))

2.4. Resolver Parameters ⚙️

2.4.1. Add Hold-Down Time 🕰️

The add hold-down time is 30 days, or the expiration time of the original TTL of the first trust point DNSKEY RRSet that contained the new key, whichever is greater 📅. This makes sure that at least two validated DNSKEY RRSets containing the new key MUST be seen by the resolver before the key is accepted 🫶.

2.4.2. Remove Hold-Down Time 🗑️

okay so the remove hold-down time is 30 days 📅 bestie, this one is purely a key management database bookkeeping parameter 🧹 if a resolver doesn't clean out info about defunct keys, the security of this protocol is still fine ✨ but the database can end up cluttered with obsolete key info 🙈

2.4.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 8 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 validating the revocation 💀

4. State Table 🦋

the most important thing to understand is the resolver's view of any key at a trust point 👀 the state table below shows that view at different points in the key's lifetime. the table is a normative part of this specification 📜 the initial state of the key is 'Start', and the resolver's view changes as events happen.

this is the state of a trust-point key as seen from the resolver. the column on the left is the current state, and the header across the top is the next state. where the two meet, you find the event that moves the key from the current state to the next one 🧩

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

                           State Table

4.1. Events 🎉

• NewKey: the resolver sees a valid DNSKEY RRSet with a new SEP key. That key becomes a new trust anchor for the named trust point once it's been in the RRSet for at least 'add time' 🔑
• KeyPres: the key is back in the valid DNSKEY RRSet 🙌
• KeyRem: the resolver sees a valid DNSKEY RRSet that doesn't include 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 long enough to get removed from the trust set 🧹
• RevBit: the key showed up in the trust anchor DNSKEY RRSet with its "REVOKED" bit set, and there's an RRSig over the DNSKEY RRSet signed by this key 🚨

4.2. States 🌸

• Start: the key doesn't exist as a trust anchor at the resolver yet 🥚 it might exist at the zone server, but either the resolver hasn't seen it yet, or it was seen and then went missing from the last DNSKEY RRSet (like a KeyRem event)
• AddPend: the key has been seen at the resolver, has its 'SEP' bit set, and has shown up in a validated DNSKEY RRSet ⏸️ there's a hold-down time before it can be used as a trust anchor
• Valid: the key has been seen at the resolver and has been in all validated DNSKEY RRSets from the moment it was first seen through the hold-down time 💖 it's now valid for verifying RRSets that arrive after the hold-down time. Clarification: the DNSKEY RRSet doesn't need to be continuously present at the resolver (its TTL might expire, for example) 🫠 if the RRSet is seen and validated (meaning it verifies against an existing trust anchor), this key MUST be in the RRSet. Otherwise, a 'KeyRem' event gets triggered.
• Missing: this is an abnormal state 🚩 the key is still a valid trust-point key, but it wasn't seen at the resolver in the last validated DNSKEY RRSet. It's abnormal because the zone operator should be using the REVOKE bit before removal.
• Revoked: this is where a key lands once the resolver sees an RRSIG(DNSKEY) signed by this key, where that DNSKEY RRSet has this key with its REVOKE bit set to '1' 🥀 once a key is here, it MUST permanently be considered invalid as a trust anchor.
• Removed: after a fairly long hold-down time, info about this key may get purged from the resolver 🌙 a key in the removed state MUST NOT be considered a valid trust anchor. (Note: this state is more or less the same as "Start", except it's bad practice to bring back keys that were used before. Think of it as the holding state for all the old keys the resolver no longer needs to track.)

5. Trust Point Deletion 🗑️

a trust point where every trust anchor has been revoked counts as deleted, and it's treated as if it was never configured 😵 if there are no superior configured trust points, data at and below the deleted trust point is considered insecure by the resolver. if there ARE superior configured trust points, data at and below the deleted trust point gets evaluated against those superior trust point(s) instead 🪜

another option: a trust point that sits under another configured trust point MAY be deleted by a resolver after 180 days, as long as that subordinate trust point validly chains up to a superior trust point ⏰ deleting the subordinate trust anchor is a local configuration decision 🏠 once it's gone, validating the subordinate zone depends on validating the chain of trust up to the superior trust point.

6. Scenarios - Informative 💫

the suggested model is one active key and one stand-by key at each trust point ✌️ the active key signs the DNSKEY RRSet. the stand-by key won't 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 isn't in active signing use, its private key may (and should) get extra protections that a key used all the time can't really have 🔒 think locked in a safe, or split up among lots of parties 🧳 the stand-by key should be less likely to get compromised than an active key, but that depends on operational concerns that aren't covered here.

6.1. Adding a Trust Anchor 🌱

assume an existing trust anchor key 'A' 🔑

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 - 'A'.
5. Wait for various resolvers' timers to go off and for them to retrieve the new DNSKEY RRSet and signatures ⏲️
6. The new trust anchor will be populated at the resolvers on the schedule described by the state table and update algorithm. See Sections 2 and 4 above.

6.2. Deleting a Trust Anchor 💅

assume existing trust anchors 'A' and 'B', and that you want to revoke and delete 'A' 🫡

1. Set the revocation 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 🥲

6.3. Key Roll-Over 🔄

assume existing keys A and B. 'A' is actively in use (it's been signing the DNSKEY RRSet), and 'B' was the stand-by key (it's been in the DNSKEY RRSet and is a valid trust anchor, but it wasn't signing 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.

6.4. Active Key Compromised 🚨

this works the same way as the Key Roll-Over mechanism (Section 6.3) above, assuming 'A' is the active key 🫠

6.5. Stand-by Key Compromised 🙈

using the same assumptions and naming conventions as Key Roll-Over (Section 6.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' stays the active key, and 'C' will be the stand-by key once the hold-down expires 💜 'B' should keep being included in the RRSet for the remove hold-down time.

6.6. Trust Point Deletion 🧨

deleting a trust point that's subordinate to another configured trust point (like example.com under .com) takes some juggling of the data 🤹‍♀️ the specific process is:

1. Generate a new DNSKEY and DS record, and provide the DS record to the parent along with the DS records for the old keys.
2. Once the parent has published the DSs, add the new DNSKEY to the RRSet and revoke ALL of the old keys at the same time, while signing the DNSKEY RRSet with all of the old and new keys.
3. After 30 days, stop publishing the old, revoked keys and remove any corresponding DS records in the parent 🗓️

Revoking the old trust-point keys at the same time as adding new keys that chain to a superior trust prevents the resolver from adding the new keys as trust anchors 🙅‍♀️ adding DS records for the old keys avoids a race condition where either the subordinate zone becomes unsecure (because the trust point was deleted) or becomes bogus (because it didn't chain to the superior zone).

7. IANA Considerations 🌈

the IANA has assigned a bit in the DNSKEY flags field (see Section 7 of [RFC4034]) for the REVOKE bit (8) 🎉

8. Security Considerations 🔐

this is serious, bestie 😤 besides the sections that follow, make sure you also check out Theory of Operation above (Section 2), especially Section 2.2 for related discussions.

security considerations for trust anchor rollover that aren't specific to this protocol are covered in [RFC4986] 🛡️

8.1. Key Ownership vs. Acceptance Policy 🎀

okay so bestie, this one is SUCH a power move 💅 The zone owner is the one who creates and hands out the keys, BUT the resolver owner is the one who gets to decide whether to actually trust them for checking zone info. Literally the final say is theirs 👑 So if a resolver owner decides to update trust-anchor keys based on a key they already trust, that's ALSO their call, not the zone owner's 🫶

The resolver owner (and the people building resolvers) MAY choose to permit or prevent key status updates from this mechanism for specific trust points 🦋 If they go with prevent, then they NEED to set up some way to update things manually or out-of-band, which is totally out of scope for this doc 💀 (not our problem bestie, but still rude to skip it 🙈)

8.2. Multiple Key Compromise 🔥

this scheme can recover as long as at least ONE valid trust-anchor key is still uncompromised 💖 Like, if you've got three keys, you can recover even if two of them got compromised. Iconic energy ✨

The zone owner should decide their own comfort level for how many active, valid trust anchors they want in a zone 🌸 and they should be ready to run recovery procedures the moment they notice a compromise 🚨 And if ALL trust-anchor keys at a trust point get compromised? Then a manual or other out-of-band update of every resolver is REQUIRED, no cap 😭

8.3. Dynamic Updates 🌈

so letting a resolver update its trust anchor set based on in-band key info is potentially less secure than doing it manually 🙈 BUT, given how DNS works, how many resolvers would need updating if a trust anchor key got compromised, and the fact that there's no standard management framework for DNS yet, this approach is no worse than what we already have 💅✨ Not perfect, but honestly kind of a W 🍓

9. Normative References 📚

• [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
• [RFC3755] Weiler, S., "Legacy Resolver Compatibility for Delegation Signer (DS)", RFC 3755, May 2004.
• [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
• [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
• [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.

10. Informative References 🦋

• [RFC4986] Eland, H., Mundy, R., Crocker, S., and S. Krishnaswamy, "Requirements Related to DNS Security (DNSSEC) Trust Anchor Rollover", RFC 4986, August 2007.

Author's Address 🧚

Michael StJohns Independent

EMail: mstjohns@comcast.net

Full Copyright Statement ⭐

Copyright (C) The IETF Trust (2007).

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.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 💜

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 http://www.ietf.org/ipr.

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 ietf-ipr@ietf.org.