rfc3445.txt revision a69a77ddfef58e93036cf6173dc7f91ed864d103
40f53fa8d9c6a4fc38c0014495e7a42b08f52481David LawrenceNetwork Working Group D. Massey
dafcb997e390efa4423883dafd100c975c4095d6Mark AndrewsRequest for Comments: 3445 USC/ISI
dafcb997e390efa4423883dafd100c975c4095d6Mark AndrewsUpdates: 2535 S. Rose
dafcb997e390efa4423883dafd100c975c4095d6Mark AndrewsCategory: Standards Track NIST
dafcb997e390efa4423883dafd100c975c4095d6Mark Andrews December 2002
dafcb997e390efa4423883dafd100c975c4095d6Mark Andrews Limiting the Scope of the KEY Resource Record (RR)
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid LawrenceStatus of this Memo
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence This document specifies an Internet standards track protocol for the
866d106459313499d0ca7bfccb4b2d23d5e4377cDavid Lawrence Internet community, and requests discussion and suggestions for
7c74e180c206e6ed99e8beb820da5f399d845c3eDavid Lawrence improvements. Please refer to the current edition of the "Internet
f31446e6b5925395fce4f62adf71f7ad70cea6ceMark Andrews Official Protocol Standards" (STD 1) for the standardization state
ea31416b4fcdf23732355a8002f93f29e3b3d2dbAndreas Gustafsson and status of this protocol. Distribution of this memo is unlimited.
03e200df5dc283f24a6a349f0b31d3eab26da893Mark AndrewsCopyright Notice
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley Copyright (C) The Internet Society (2002). All Rights Reserved.
a5d43b72413db3edd6b36a58f9bdf2cf6ff692f2Bob Halley This document limits the Domain Name System (DNS) KEY Resource Record
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff (RR) to only keys used by the Domain Name System Security Extensions
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff (DNSSEC). The original KEY RR used sub-typing to store both DNSSEC
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff keys and arbitrary application keys. Storing both DNSSEC and
a903095bf4512dae561c7f6fc7854a51bebf334aMark Andrews application keys with the same record type is a mistake. This
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff document removes application keys from the KEY record by redefining
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff the Protocol Octet field in the KEY RR Data. As a result of removing
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff application keys, all but one of the flags in the KEY record become
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff unnecessary and are redefined. Three existing application key sub-
3d776d762914d1b675b4fd49728ce353ccf6f77eBrian Wellington types are changed to reserved, but the format of the KEY record is
ccdac53c027e8964753b36c4d8c7b0e98af501c2Michael Graff not changed. This document updates RFC 2535.
03e200df5dc283f24a6a349f0b31d3eab26da893Mark Andrews1. Introduction
03e200df5dc283f24a6a349f0b31d3eab26da893Mark Andrews This document limits the scope of the KEY Resource Record (RR). The
03e200df5dc283f24a6a349f0b31d3eab26da893Mark Andrews KEY RR was defined in [3] and used resource record sub-typing to hold
03e200df5dc283f24a6a349f0b31d3eab26da893Mark Andrews arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
03e200df5dc283f24a6a349f0b31d3eab26da893Mark Andrews This document eliminates the existing Email, IPSEC, and TLS sub-types
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence and prohibits the introduction of new sub-types. DNSSEC will be the
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence only allowable sub-type for the KEY RR (hence sub-typing is
75a4dd0d377dca2f85cea44e28bf110314c1fe8cDavid Lawrence essentially eliminated) and all but one of the KEY RR flags are also
e893dce91279d7313a579f72caae3941f6dc5a27David LawrenceMassey & Rose Standards Track [Page 1]
e893dce91279d7313a579f72caae3941f6dc5a27David LawrenceRFC 3445 Limiting the KEY Resource Record (RR) December 2002
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence Section 2 presents the motivation for restricting the KEY record and
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence Section 3 defines the revised KEY RR. Sections 4 and 5 summarize the
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence changes from RFC 2535 and discuss backwards compatibility. It is
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence important to note that this document restricts the use of the KEY RR
e893dce91279d7313a579f72caae3941f6dc5a27David Lawrence and simplifies the flags, but does not change the definition or use
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley of DNSSEC keys.
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
ce8c568e0d6106bb87069453505e09bc66754b40Andreas Gustafsson document are to be interpreted as described in RFC 2119 [1].
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley2. Motivation for Restricting the KEY RR
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley Algorithm type, and a Public Key. The Protocol Octet identifies the
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley KEY RR sub-type. DNSSEC public keys are stored in the KEY RR using a
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley Protocol Octet value of 3. Email, IPSEC, and TLS keys were also
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley stored in the KEY RR and used Protocol Octet values of 1,2, and 4
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley (respectively). Protocol Octet values 5-254 were available for
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley assignment by IANA and values were requested (but not assigned) for
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley applications such as SSH.
3b77946b751f39bd4db5a7d1fe48a81e6b1e7a28Bob Halley Any use of sub-typing has inherent limitations. A resolver can not
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff specify the desired sub-type in a DNS query and most DNS operations
8e06cea14c857429ab7e7299af2dce5eeeaa5ff0Michael Graff apply only to resource records sets. For example, a resolver can not
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson directly request the DNSSEC subtype KEY RRs. Instead, the resolver
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson has to request all KEY RRs associated with a DNS name and then search
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson the set for the desired DNSSEC sub-type. DNSSEC signatures also
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson apply to the set of all KEY RRs associated with the DNS name,
3ecf3394e37dc2848a09ffc643565d454e9e6974Andreas Gustafsson regardless of sub-type.
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence In the case of the KEY RR, the inherent sub-type limitations are
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence exacerbated since the sub-type is used to distinguish between DNSSEC
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence keys and application keys. DNSSEC keys and application keys differ
b587e1d83f007ce68a9ae93097c461d8eb7aa373Mark Andrews in virtually every respect and Section 2.1 discusses these
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence differences in more detail. Combining these very different types of
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence keys into a single sub-typed resource record adds unnecessary
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence complexity and increases the potential for implementation and
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence deployment errors. Limited experimental deployment has shown that
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence application keys stored in KEY RRs are problematic.
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence This document addresses these issues by removing all application keys
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence from the KEY RR. Note that the scope of this document is strictly
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence limited to the KEY RR and this document does not endorse or restrict
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence the storage of application keys in other, yet undefined, resource
ae4cbb69eef32ced103fe4561e8d2031ee4c3497David LawrenceMassey & Rose Standards Track [Page 2]
289ae548d52bc8f982d9823af64cafda7bd92232Mark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews2.1 Differences Between DNSSEC and Application Keys
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews DNSSEC keys are an essential part of the DNSSEC protocol and are used
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews by both name servers and resolvers in order to perform DNS tasks. A
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews DNS zone key, used to sign and authenticate RR sets, is the most
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews common example of a DNSSEC key. SIG(0) [4] and TKEY [3] also use
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews DNSSEC keys.
ae4cbb69eef32ced103fe4561e8d2031ee4c3497David Lawrence Application keys such as Email keys, IPSEC keys, and TLS keys are
ae4cbb69eef32ced103fe4561e8d2031ee4c3497David Lawrence simply another type of data. These keys have no special meaning to a
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence name server or resolver.
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence The following table summarizes some of the differences between DNSSEC
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence keys and application keys:
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence 1. They serve different purposes.
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence 2. They are managed by different administrators.
0293ad13207aa29bd5844cdc87d085ffc009d749David Lawrence 3. They are authenticated according to different rules.
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews 4. Nameservers use different rules when including them in
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews 5. Resolvers process them in different ways.
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews 6. Faults/key compromises have different consequences.
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews 1. The purpose of a DNSSEC key is to sign resource records
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews associated with a DNS zone (or generate DNS transaction signatures in
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews the case of SIG(0)/TKEY). But the purpose of an application key is
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews specific to the application. Application keys, such as PGP/email,
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews the purpose and proper use of application keys is outside the scope
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence 2. DNSSEC keys are managed by DNS administrators, but application
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence keys are managed by application administrators. The DNS zone
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence administrator determines the key lifetime, handles any suspected key
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence compromises, and manages any DNSSEC key changes. Likewise, the
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence application administrator is responsible for the same functions for
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence the application keys related to the application. For example, a user
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence typically manages her own PGP key and a server manages its own TLS
df3c4c7988b9bae7d121a8ac9ed17a23366a948dDavid Lawrence key. Application key management tasks are outside the scope of DNS
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff administration.
289ae548d52bc8f982d9823af64cafda7bd92232Mark AndrewsMassey & Rose Standards Track [Page 3]
289ae548d52bc8f982d9823af64cafda7bd92232Mark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence 3. DNSSEC zone keys are used to authenticate application keys, but
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence by definition, application keys are not allowed to authenticate DNS
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence zone keys. A DNS zone key is either configured as a trusted key or
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence authenticated by constructing a chain of trust in the DNS hierarchy.
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence To participate in the chain of trust, a DNS zone needs to exchange
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence zone key information with its parent zone [3]. Application keys are
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence not configured as trusted keys in the DNS and are never part of any
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence DNS chain of trust. Application key data is not needed by the parent
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence and does not need to be exchanged with the parent zone for secure DNS
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence resolution to work. A resolver considers an application key RRset as
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence authenticated DNS information if it has a valid signature from the
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence local DNS zone keys, but applications could impose additional
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence security requirements before the application key is accepted as
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence authentic for use with the application.
4bcaefbcd3ced942139fdc830e007c6ea2b8d2feDavid Lawrence 4. It may be useful for nameservers to include DNS zone keys in the
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff additional section of a response, but application keys are typically
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff not useful unless they have been specifically requested. For
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff example, it could be useful to include the example.com zone key along
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff with a response that contains the www.example.com A record and SIG
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff record. A secure resolver will need the example.com zone key in
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff order to check the SIG and authenticate the www.example.com A record.
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff It is typically not useful to include the IPSEC, email, and TLS keys
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff along with the A record. Note that by placing application keys in
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff the KEY record, a resolver would need the IPSEC, email, TLS, and
657ce0b9d84fbd66514df53d61a087e8f1161187Michael Graff other key associated with example.com if the resolver intends to
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson authenticate the example.com zone key (since signatures only apply to
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson the entire KEY RR set). Depending on the number of protocols
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews involved, the KEY RR set could grow unwieldy for resolvers, and DNS
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews administrators to manage.
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews 5. DNS zone keys require special handling by resolvers, but
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews application keys are treated the same as any other type of DNS data.
80badf38c74c326a694e24281ee258aa26984171Mark Andrews The DNSSEC keys are of no value to end applications, unless the
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews applications plan to do their own DNS authentication. By definition,
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews secure resolvers are not allowed to use application keys as part of
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews the authentication process. Application keys have no unique meaning
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews to resolvers and are only useful to the application requesting the
641da3ca1184d9951d5cf91538524a345bf5f271Mark Andrews key. Note that if sub-types are used to identify the application
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews key, then either the interface to the resolver needs to specify the
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews sub-type or the application needs to be able to accept all KEY RRs
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews and pick out the desired sub-type.
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews 6. A fault or compromise of a DNS zone key can lead to invalid or
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews forged DNS data, but a fault or compromise of an application key
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews should have no impact on other DNS data. Incorrectly adding or
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews changing a DNS zone key can invalidate all of the DNS data in the
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews zone and in all of its subzones. By using a compromised key, an
774c3a62d9adca187b44fe90919bb409a43a2f2aMark AndrewsMassey & Rose Standards Track [Page 4]
774c3a62d9adca187b44fe90919bb409a43a2f2aMark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews attacker can forge data from the effected zone and for any of its
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews sub-zones. A fault or compromise of an application key has
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews implications for that application, but it should not have an impact
774c3a62d9adca187b44fe90919bb409a43a2f2aMark Andrews on the DNS. Note that application key faults and key compromises can
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews have an impact on the entire DNS if the application key and DNS zone
9fe28a624c659e380d47dbf45527637dab03b998Mark Andrews keys are both stored in the KEY RR.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson In summary, DNSSEC keys and application keys differ in most every
39b973d8873996c3bfb6e5b4cc69731f6c3b77b5Mark Andrews respect. DNSSEC keys are an essential part of the DNS infrastructure
6342df69b05f2f62d060fd4affdf536e51504084Mark Andrews and require special handling by DNS administrators and DNS resolvers.
6342df69b05f2f62d060fd4affdf536e51504084Mark Andrews Application keys are simply another type of data and have no special
6342df69b05f2f62d060fd4affdf536e51504084Mark Andrews meaning to DNS administrators or resolvers. These two different
6342df69b05f2f62d060fd4affdf536e51504084Mark Andrews types of data do not belong in the same resource record.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson3. Definition of the KEY RR
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson The KEY RR uses type 25 and is used as resource record for storing
c654449ccf403ccd2b81be2038b1013d6fbb06ccMark Andrews DNSSEC keys. The RDATA for a KEY RR consists of flags, a protocol
6fcb2f0faad67a6d2cb2e30ec57157d75fbfe58fAndreas Gustafsson octet, the algorithm number octet, and the public key itself. The
6fcb2f0faad67a6d2cb2e30ec57157d75fbfe58fAndreas Gustafsson format is as follows:
6fcb2f0faad67a6d2cb2e30ec57157d75fbfe58fAndreas Gustafsson ---------------------------------------------------------------------
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington | flags | protocol | algorithm |
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington / public key /
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
47fd46791da765e3dbedd987e9b263b3bee25986Brian Wellington KEY RR Format
6fcb2f0faad67a6d2cb2e30ec57157d75fbfe58fAndreas Gustafsson ---------------------------------------------------------------------
6fcb2f0faad67a6d2cb2e30ec57157d75fbfe58fAndreas Gustafsson In the flags field, all bits except bit 7 are reserved and MUST be
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson zero. If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
8f3dd8f8e73e4465221a5297819db70e6b383138Mark Andrews key. If Bit 7 is set to 0, the KEY is not a zone key. SIG(0)/TKEY
6e9efadbea9febb0494e713e54dfea6f7ef70383Mark Andrews are examples of DNSSEC keys that are not zone keys.
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark Andrews The protocol field MUST be set to 3.
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark Andrews The algorithm and public key fields are not changed.
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark AndrewsMassey & Rose Standards Track [Page 5]
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark Andrews4. Changes from RFC 2535 KEY RR
43fe2897fc80bbec2115310ca79d432a252f3ea4Mark Andrews The KEY RDATA format is not changed.
754cca729dd82ae8363917dc00ad44f9d900635bMark Andrews All flags except for the zone key flag are eliminated:
754cca729dd82ae8363917dc00ad44f9d900635bMark Andrews The A/C bits (bits 0 and 1) are eliminated. They MUST be set to 0
754cca729dd82ae8363917dc00ad44f9d900635bMark Andrews and MUST be ignored by the receiver.
754cca729dd82ae8363917dc00ad44f9d900635bMark Andrews The extended flags bit (bit 3) is eliminated. It MUST be set to 0
754cca729dd82ae8363917dc00ad44f9d900635bMark Andrews and MUST be ignored by the receiver.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews The host/user bit (bit 6) is eliminated. It MUST be set to 0 and
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews MUST be ignored by the receiver.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews The zone bit (bit 7) remains unchanged.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews The signatory field (bits 12-15) are eliminated by [5]. They MUST
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews be set to 0 and MUST be ignored by the receiver.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews Bits 2,4,5,8,9,10,11 remain unchanged. They are reserved, MUST be
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews set to zero and MUST be ignored by the receiver.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews Assignment of any future KEY RR Flag values requires a standards
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews All Protocol Octet values except DNSSEC (3) are eliminated:
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews Value 1 (Email) is renamed to RESERVED.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews Value 2 (IPSEC) is renamed to RESERVED.
40dd9cb8cc240c33d820fe79f176ed51e4c06a1aMark Andrews Value 3 (DNSSEC) is unchanged.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson Value 4 (TLS) is renamed to RESERVED.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson Value 5-254 remains unchanged (reserved).
963c48ba4d06a112c70d50328e827749e95f58dbMark Andrews Value 255 (ANY) is renamed to RESERVED.
963c48ba4d06a112c70d50328e827749e95f58dbMark Andrews The authoritative data for a zone MUST NOT include any KEY records
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson with a protocol octet other than 3. The registry maintained by IANA
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson for protocol values is closed for new assignments.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson RRs with a value other than 3. If out of date DNS zones contain
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson deprecated KEY RRs with a protocol octet value other than 3, then
a1898260ad19d02e88ab76c1855d33c67add9defMark Andrews simply dropping the deprecated KEY RRs from the KEY RR set would
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas GustafssonMassey & Rose Standards Track [Page 6]
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas GustafssonRFC 3445 Limiting the KEY Resource Record (RR) December 2002
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson invalidate any associated SIG record(s) and could create caching
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson consistency problems. Note that KEY RRs with a protocol octet value
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson other than 3 MUST NOT be used to authenticate DNS data.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson The algorithm and public key fields are not changed.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson5. Backward Compatibility
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson DNSSEC zone KEY RRs are not changed and remain backwards compatible.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson A properly formatted RFC 2535 zone KEY would have all flag bits,
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson Octet set to 3. This remains true under the restricted KEY.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson but the distinction between host and user keys (flag bit 6) is lost.
5ff133b82082d82f0ba89b7c999c6b62b6298e46Andreas Gustafsson No backwards compatibility is provided for application keys. Any
90407942d3afe50f04ccea361de3b164a5a1702dMichael Graff Email, IPSEC, or TLS keys are now deprecated. Storing application
90407942d3afe50f04ccea361de3b164a5a1702dMichael Graff keys in the KEY RR created problems such as keys at the apex and
90407942d3afe50f04ccea361de3b164a5a1702dMichael Graff large RR sets and some change in the definition and/or usage of the
90407942d3afe50f04ccea361de3b164a5a1702dMichael Graff KEY RR would have been required even if the approach described here
90407942d3afe50f04ccea361de3b164a5a1702dMichael Graff were not adopted.
13faa8b6a2d0d45e0659049983928366252ab3faMichael Graff Overall, existing nameservers and resolvers will continue to
13faa8b6a2d0d45e0659049983928366252ab3faMichael Graff correctly process KEY RRs with a sub-type of DNSSEC keys.
3ca0e71a863fe3fbb4f439e5d0bebfd7bd38fb16Mark Andrews6. Storing Application Keys in the DNS
13faa8b6a2d0d45e0659049983928366252ab3faMichael Graff The scope of this document is strictly limited to the KEY record.
61d5bfc06be978ea962b1c64309894ac80351771Mark Andrews This document prohibits storing application keys in the KEY record,
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews but it does not endorse or restrict the storing application keys in
3d8dfd44a3be708f00380064411c16b2fa28303aMark Andrews other record types. Other documents can describe how DNS handles
13faa8b6a2d0d45e0659049983928366252ab3faMichael Graff application keys.
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews7. IANA Considerations
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews values. Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews values 5-254 were made available for assignment by IANA. This
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews document makes two sets of changes to this registry.
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews First, this document re-assigns DNS KEY RR Protocol Octet values 1,
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews 2, 4, and 255 to "reserved". DNS Key RR Protocol Octet Value 3
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews remains unchanged as "DNSSEC".
a53259c4cc558f86dd008eccc60cc89b6734a03cMark AndrewsMassey & Rose Standards Track [Page 7]
a53259c4cc558f86dd008eccc60cc89b6734a03cMark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
5f9e583552f53de12062bfff12e47250abce378fBrian Wellington Second, new values are no longer available for assignment by IANA and
a53259c4cc558f86dd008eccc60cc89b6734a03cMark Andrews this document closes the IANA registry for DNS KEY RR Protocol Octet
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson Values. Assignment of any future KEY RR Protocol Octet values
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews requires a standards action.
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson8. Security Considerations
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson This document eliminates potential security problems that could arise
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews due to the coupling of DNS zone keys and application keys. Prior to
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson the change described in this document, a correctly authenticated KEY
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson set could include both application keys and DNSSEC keys. This
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson document restricts the KEY RR to DNS security usage only. This is an
68f72235f8f41fa949823551d8e6476057ec5bd6Andreas Gustafsson attempt to simplify the security model and make it less user-error
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson prone. If one of the application keys is compromised, it could be
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews used as a false zone key to create false DNS signatures (SIG
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson records). Resolvers that do not carefully check the KEY sub-type
80f323528ac699026a609a5e3b765dc6e88fe37cAndreas Gustafsson could believe these false signatures and incorrectly authenticate DNS
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson data. With this change, application keys cannot appear in an
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson authenticated KEY set and this vulnerability is eliminated.
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews The format and correct usage of DNSSEC keys is not changed by this
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews document and no new security considerations are introduced.
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews9. Normative References
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews Levels", BCP 14, RFC 2119, March 1997.
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews [2] Eastlake, D., "Domain Name System Security Extensions", RFC
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews 2535, March 1999.
f8f65e2de40b1e9874b88f392f3abeb057ce6172Mark Andrews [3] Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
f8f65e2de40b1e9874b88f392f3abeb057ce6172Mark Andrews 2930, September 2000.
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews [4] Eastlake, D., "DNS Request and Transaction Signatures
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews (SIG(0)s)", RFC 2931, September 2000.
c5826852e6c789f59b301f8197e65a1dd4e09a44Mark Andrews [5] Wellington, B., "Secure Domain Name System (DNS) Dynamic
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews Update", RFC 3007, November 2000.
bc53aacc6e9302b1f8d01467fc39585584652782Andreas GustafssonMassey & Rose Standards Track [Page 8]
bc53aacc6e9302b1f8d01467fc39585584652782Andreas GustafssonRFC 3445 Limiting the KEY Resource Record (RR) December 2002
2995f8205eaa0d4bc3a57900a413b5cfdb83564fAndreas Gustafsson10. Authors' Addresses
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews USC Information Sciences Institute
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews 3811 N. Fairfax Drive
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews Arlington, VA 22203
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews EMail: masseyd@isi.edu
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews National Institute for Standards and Technology
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews 100 Bureau Drive
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews Gaithersburg, MD 20899-3460
d73de275987d29627dc11d5bd4a22874a29f7874Mark Andrews EMail: scott.rose@nist.gov
fda0a038810529d6e45b17822ddcc61d82964e83Mark AndrewsMassey & Rose Standards Track [Page 9]
fda0a038810529d6e45b17822ddcc61d82964e83Mark AndrewsRFC 3445 Limiting the KEY Resource Record (RR) December 2002
c0707105f60934d59321c2fccbc254f9e31ff28aMark Andrews11. Full Copyright Statement
c0707105f60934d59321c2fccbc254f9e31ff28aMark Andrews Copyright (C) The Internet Society (2002). All Rights Reserved.
c0707105f60934d59321c2fccbc254f9e31ff28aMark Andrews This document and translations of it may be copied and furnished to
c0707105f60934d59321c2fccbc254f9e31ff28aMark Andrews others, and derivative works that comment on or otherwise explain it
c0707105f60934d59321c2fccbc254f9e31ff28aMark Andrews or assist in its implementation may be prepared, copied, published
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson and distributed, in whole or in part, without restriction of any
5989aea4bbe79e09290792f04aeb557e2b2da02eAndreas Gustafsson kind, provided that the above copyright notice and this paragraph are
5f9e583552f53de12062bfff12e47250abce378fBrian Wellington included on all such copies and derivative works. However, this
5f9e583552f53de12062bfff12e47250abce378fBrian Wellington document itself may not be modified in any way, such as by removing
08a768e82ad64ede97f640c88e02984b59122753Michael Graff the copyright notice or references to the Internet Society or other
08a768e82ad64ede97f640c88e02984b59122753Michael Graff Internet organizations, except as needed for the purpose of
08a768e82ad64ede97f640c88e02984b59122753Michael Graff developing Internet standards in which case the procedures for
08a768e82ad64ede97f640c88e02984b59122753Michael Graff copyrights defined in the Internet Standards process must be
08a768e82ad64ede97f640c88e02984b59122753Michael Graff followed, or as required to translate it into languages other than
0e40083fdd5445703bd30e46e5bfe7d047bced12Brian Wellington The limited permissions granted above are perpetual and will not be
0e40083fdd5445703bd30e46e5bfe7d047bced12Brian Wellington revoked by the Internet Society or its successors or assigns.
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews This document and the information contained herein is provided on an
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
289ae548d52bc8f982d9823af64cafda7bd92232Mark AndrewsAcknowledgement
289ae548d52bc8f982d9823af64cafda7bd92232Mark Andrews Funding for the RFC Editor function is currently provided by the
65cfc4e0e3e24a7410d6fe8505455fc85f62215cMark Andrews Internet Society.
289ae548d52bc8f982d9823af64cafda7bd92232Mark AndrewsMassey & Rose Standards Track [Page 10]