draft-ietf-dnssec-secext-07.txt   draft-ietf-dnssec-secext-08.txt 
DNS Security Working Group Donald E. Eastlake, 3rd DNS Security Working Group Donald E. Eastlake 3rd
INTERNET-DRAFT CyberCash INTERNET-DRAFT CyberCash
UPDATES RFC 1034, 1035 Charles W. Kaufman UPDATES RFC 1034, 1035 Charles W. Kaufman
Iris Iris
Expires: 27 June 1996 28 December 1995 Expires: 8 July 1996 9 January 1996
Domain Name System Security Extensions Domain Name System Security Extensions
------ ---- ------ -------- ---------- ------ ---- ------ -------- ----------
Status of This Document Status of This Document
This draft, file name draft-ietf-dnssec-secext-07.txt, is intended to This draft, file name draft-ietf-dnssec-secext-08.txt, is intended to
be become a Proposed Standard RFC. Distribution of this document is be become a Proposed Standard RFC. Distribution of this document is
unlimited. Comments should be sent to the DNS Security Working Group unlimited. Comments should be sent to the DNS Security Working Group
mailing list <dns-security@tis.com> or to the authors. mailing list <dns-security@tis.com> or to the authors.
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 3, line 52 skipping to change at page 3, line 52
4.1.3 Zone Transfer (AXFR) SIG............................23 4.1.3 Zone Transfer (AXFR) SIG............................23
4.1.4 Transaction and Request SIGs........................24 4.1.4 Transaction and Request SIGs........................24
4.2 SIG RRs in the Construction of Responses..............24 4.2 SIG RRs in the Construction of Responses..............24
4.3 Processing Responses and SIG RRs......................25 4.3 Processing Responses and SIG RRs......................25
4.4 Signature Expiration, TTLs, and Validity..............26 4.4 Signature Expiration, TTLs, and Validity..............26
4.5 File Representation of SIG RRs........................26 4.5 File Representation of SIG RRs........................26
5. Non-existent Names and Types...........................28 5. Non-existent Names and Types...........................28
5.1 The NXT Resource Record...............................28 5.1 The NXT Resource Record...............................28
5.2 NXT RDATA Format......................................29 5.2 NXT RDATA Format......................................29
5.3 Example...............................................29 5.3 Example...............................................30
5.4 Interaction of NXT RRs and Wildcard RRs...............30 5.4 Interaction of NXT RRs and Wildcard RRs...............30
5.5 Blocking NXT Pseudo-Zone Transfers....................31 5.5 Blocking NXT Pseudo-Zone Transfers....................31
5.6 Special Considerations at Delegation Points...........31 5.6 Special Considerations at Delegation Points...........32
6. The AD and CD Bits and How to Resolve Securely.........33 6. The AD and CD Bits and How to Resolve Securely.........33
6.1 The AD and CD Header Bits.............................33 6.1 The AD and CD Header Bits.............................33
6.2 Boot File Format......................................34 6.2 Boot File Format......................................34
6.3 Chaining Through Zones................................35 6.3 Chaining Through Zones................................35
6.4 Secure Time...........................................36 6.4 Secure Time...........................................36
7. Operational Considerations.............................37 7. Operational Considerations.............................37
7.1 Key Size Considerations...............................37 7.1 Key Size Considerations...............................37
7.2 Key Storage...........................................37 7.2 Key Storage...........................................37
skipping to change at page 6, line 38 skipping to change at page 6, line 38
2.2 Key Distribution 2.2 Key Distribution
Resource records (RRs) are defined to associate keys with DNS names. Resource records (RRs) are defined to associate keys with DNS names.
This permits the DNS to be used as a general public key distribution This permits the DNS to be used as a general public key distribution
mechanism in support of the data origin authentication and mechanism in support of the data origin authentication and
transaction authentication DNS services as well as other security transaction authentication DNS services as well as other security
services. services.
The syntax of a KEY resource record (RR) is described in Section 3. The syntax of a KEY resource record (RR) is described in Section 3.
It includes an algorithm identifier, flags indicating the type of It includes an algorithm identifier, the actual public key
entity the key is associated with and/or asserting that there is no parameters, and a variety of flags including those indicating the
key associated with that entity, and the actual public key type of entity the key is associated with and/or asserting that there
parameters. is no key associated with that entity.
Under conditions described in Section 3, security aware DNS servers Under conditions described in Section 3, security aware DNS servers
may automatically attempt to return KEY resources as additional will automatically attempt to return KEY resources as additional
information, along with those resource records actually requested, to information, along with those resource records actually requested, to
minimize the number of queries needed. minimize the number of queries needed.
2.3 Data Origin Authentication and Integrity 2.3 Data Origin Authentication and Integrity
Authentication is provided by associating with resource records in Authentication is provided by associating with resource records in
the DNS cryptographically generated digital signatures. Commonly, the DNS cryptographically generated digital signatures. Commonly,
there will be a single private key that signs for an entire zone. If there will be a single private key that signs for an entire zone. If
a security aware resolver reliably learns the public key of the zone, a security aware resolver reliably learns the public key of the zone,
it can verify, for signed data read from that zone, that it was it can verify, for signed data read from that zone, that it was
skipping to change at page 12, line 35 skipping to change at page 12, line 35
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | protocol | algorithm | | flags | protocol | algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
/ public key / / public key /
/ / / /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
The meaning of the KEY RR owner name, flags, and protocol octet are The meaning of the KEY RR owner name, flags, and protocol octet are
described in Sections 3.2, 3.3 and 3.4 below respectively. The flags described in Sections 3.2, 3.3 and 3.4 below respectively. The flags
and protocol must be examined before any data following the algorithm and algorithm must be examined before any data following the
octet as they control the format and even whether there is any algorithm octet as they control the format and even whether there is
following data. The algorithm and public key fields are described in any following data. The algorithm and public key fields are
Section 3.5. The format of the public key is algorithm dependent. described in Section 3.5. The format of the public key is algorithm
dependent.
3.2 Object Types, DNS Names, and Keys 3.2 Object Types, DNS Names, and Keys
The public key in a KEY RR belongs to the object named in the owner The public key in a KEY RR belongs to the object named in the owner
name. name.
This DNS name may refer to up to three different categories of This DNS name may refer to up to three different categories of
things. For example, dee.cybercash.com could be (1) a zone, (2) a things. For example, dee.cybercash.com could be (1) a zone, (2) a
host or other end entity , and (3) the mapping into a DNS name of the host or other end entity , and (3) the mapping into a DNS name of the
user or account dee@cybercash.com. Thus, there are flags, as user or account dee@cybercash.com. Thus, there are flags, as
skipping to change at page 13, line 25 skipping to change at page 13, line 26
It would be desirable for the growth of DNS to be managed so that It would be desirable for the growth of DNS to be managed so that
additional possible simultaneous uses for names are NOT added. New additional possible simultaneous uses for names are NOT added. New
uses should be distinguished by exclusive domains. For example, all uses should be distinguished by exclusive domains. For example, all
IP autonomous system numbers have been mapped into the in-as.arpa IP autonomous system numbers have been mapped into the in-as.arpa
domain [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if domain [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if
issued simultaneously with this draft)], all telephone numbers in the issued simultaneously with this draft)], all telephone numbers in the
world have been mapped into the tpc.int domain [RFC 1530], and all world have been mapped into the tpc.int domain [RFC 1530], and all
IPv4 addresses (i.e., all IPv4 globally addressable interfaces) have IPv4 addresses (i.e., all IPv4 globally addressable interfaces) have
been mapped into the in-addr.arpa domain. This is much preferable to been mapped into the in-addr.arpa domain. This is much preferable to
having the same name possibly be an autonomous system number, having the same fully qualified name simultaneously be a possible
telephone number, IPv4 interface, and/or host as well as a zone and a autonomous system number, telephone number, IPv4 interface, and/or
user. host as well as a zone and a user.
In addition to the name type bits, there are additional control bits In addition to the name type bits, there are additional flag bits
including the "no key" bit, "experimental" bit, "signatory" field, including the "type" field, "experimental" bit, "signatory" field,
etc., as described below. etc., as described below.
3.3 The KEY RR Flag Field 3.3 The KEY RR Flag Field
In the "flags" field: In the "flags" field:
Bit 0 is the "no key" bit. If this bit is on, there is no key Bit 0 and 1 are the "type" field. Bit 0 a one indicates that
information and the RR stops after the algorithm octet. By the use use of the key is prohibited for authentication. Bit 1 a one
of this bit, a signed KEY RR can authenticatably assert that, for indicates that use of the key is prohibited for confidentiality. If
example, a zone is not secured. this field is zero, then use of the key for authentication and/or
confidentiality is permitted. Note that DNS security makes use of
keys for authentication only. Confidentiality use flagging is
provided for use of keys in other protocols. If both bits of this
field are one, "no key" value, there is no key information and the RR
stops after the algorithm octet. By the use of this "no key" value,
a signed KEY RR can authenticatably assert that, for example, a zone
is not secured.
Bit 1 is the "experimental" bit. It is ignored if the "no key" Bit 2 is the "experimental" bit. It is ignored if the type
bit is on and the following description assumes the "no key" bit to field indicates "no key" and the following description assumes that
be off. Keys may be associated with zones, entities, or users for type field to be non-zero. Keys may be associated with zones,
experimental, trial, or optional use, in which case this bit will be entities, or users for experimental, trial, or optional use, in which
one. If this bit is a zero, it means that the use or availability of case this bit will be one. If this bit is a zero, it means that the
security based on the key is "mandatory". Thus, if this bit is off use or availability of security based on the key is "mandatory".
for a zone key, the zone should be assumed secured by SIG RRs and any Thus, if this bit is off for a zone key, the zone should be assumed
responses indicating the zone is not secured should be considered secured by SIG RRs and any responses indicating the zone is not
bogus. If this bit is a one for a host or end entity, it might secured should be considered bogus. If this bit is a one for a host
sometimes operate in a secure mode and at other times operate without or end entity, it might sometimes operate in a secure mode and at
security. The experimental bit, like all other aspects of the KEY other times operate without security. The experimental bit, like all
RR, is only effective if the KEY RR is appropriately signed by a SIG other aspects of the KEY RR, is only effective if the KEY RR is
RR. The experimental bit must be zero for safe secure operation and appropriately signed by a SIG RR. The experimental bit must be zero
should only be a one for a minimal transition period. for safe secure operation and should only be a one for a minimal
transition period.
Bits 2-4 are reserved and must be zero. Bits 3-4 are reserved and must be zero.
Bit 5 on indicates that this is a key associated with a "user" Bit 5 on indicates that this is a key associated with a "user"
or "account" at an end entity, usually a host. The coding of the or "account" at an end entity, usually a host. The coding of the
owner name is that used for the responsible individual mailbox in the owner name is that used for the responsible individual mailbox in the
SOA and RP RRs: The owner name is the user name as the name of a node SOA and RP RRs: The owner name is the user name as the name of a node
under the entity name. For example, "j.random_user" on under the entity name. For example, "j.random_user" on
host.subdomain.domain could have a public key associated through a host.subdomain.domain could have a public key associated through a
KEY RR with name j\.random_user.host.subdomain.domain. It could be KEY RR with name j\.random_user.host.subdomain.domain and the user
used in an security protocol where authentication of a user was bit a one. It could be used in an security protocol where
desired. This key would be useful in IP or other security for a user authentication of a user was desired. This key might be useful in IP
level service such a telnet, ftp, rlogin, etc. or other security for a user level service such a telnet, ftp,
rlogin, etc.
Bit 6 on indicates that this is a key associated with the non- Bit 6 on indicates that this is a key associated with the non-
zone "entity" whose name is the RR owner name. This will commonly be zone "entity" whose name is the RR owner name. This will commonly be
a host but could, in some parts of the DNS tree, be some other type a host but could, in some parts of the DNS tree, be some other type
of entity such as a telephone number [RFC 1530] or autonomous system of entity such as a telephone number [RFC 1530] or autonomous system
number [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if number [draft-ietf-dnssec-as-map-*.txt (may have an RFC number if
issued simultaneously with this draft)]. This is the public key used issued simultaneously with this draft)]. This is the public key used
in connection with the optional DNS transaction authentication in connection with the optional DNS transaction authentication
service if the owner name is a DNS server host. It could also be service if the owner name is a DNS server host. It could also be
used in an IP-security protocol where authentication of at the host, used in an IP-security protocol where authentication of at the host,
rather than user, level was desired, such as routing, NTP, etc. rather than user, level was desired, such as routing, NTP, etc.
Bit 7 is the "zone" bit and indicates that this is a zone key Bit 7 is the "zone" bit and indicates that this is a zone key
for the zone whose name is the KEY RR owner name. This is the for the zone whose name is the KEY RR owner name. This is the
primary type of DNS data origin authentication public key. primary type of DNS data origin authentication public key.
Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicate Bit 8 is reserved to be the IPSEC [RFC 1825] bit and indicate
that this key is valid for use in conjunction with that IP level that this key is valid for use in conjunction with that security
security standard. This key could be used in connection with secured standard. This key could be used in connection with secured
communication on behalf of an end entity or user whose name is the communication on behalf of an end entity or user whose name is the
owner name of the KEY RR if the entity or user bits are on. The owner name of the KEY RR if the entity or user bits are on. The
presence of a KEY resource with the IPSEC and entity bits on and presence of a KEY resource with the IPSEC and entity bits on and
experimental and no-key bits off is a guarantee that the host speaks experimental and no-key bits off is a guarantee that the host speaks
IPSEC. IPSEC.
Bit 9 is reserved to be the "email" bit and indicate that this Bit 9 is reserved to be the "email" bit and indicate that this
key is valid for use in conjunction with MIME security multiparts. key is valid for use in conjunction with MIME security multiparts.
This key could be used in connection with secured communication on This key could be used in connection with secured communication on
behalf of an end entity or user whose name is the owner name of the behalf of an end entity or user whose name is the owner name of the
skipping to change at page 15, line 45 skipping to change at page 16, line 6
It is intended that new uses of DNS stored keys would initially be It is intended that new uses of DNS stored keys would initially be
implemented, and operational experience gained, using the implemented, and operational experience gained, using the
experimental range of the protocol octet. If demand for widespread experimental range of the protocol octet. If demand for widespread
deployment for the indefinite future warrants, a value in the deployment for the indefinite future warrants, a value in the
assigned range would then be designated for the protocol. Finally, assigned range would then be designated for the protocol. Finally,
(1) should the protocol become so widespread in conjunction with (1) should the protocol become so widespread in conjunction with
other protocols and with which it shares key values that duplicate other protocols and with which it shares key values that duplicate
RRs are a serious burden and (2) should the protocol provide RRs are a serious burden and (2) should the protocol provide
substantial facilities not available in any protocol for which a substantial facilities not available in any protocol for which a
flags field bit has been allocated, then a flag field bit may be flags field bit has been allocated, then one of the four remaining
allocated to the protocol. When such a bit has been allocated, a key flag field bits may be allocated to the protocol. When such a bit has
can be simultaneously indicated as valid for that protocol and the been allocated, a key can be simultaneously indicated as valid for
entity or host can be simultaneously flagged as implementing the that protocol and the entity or host can be simultaneously flagged as
secure version of that protocol, along with other protocols for which implementing the secure version of that protocol, along with other
flag field bits have been assigned. protocols for which flag field bits have been assigned.
Note that the IPSEC protocol being developed may provide facilities Note that the IPSEC protocol being developed may provide facilities
adequate for all point to point IP communication meaning that adequate for all point to point communication over IP meaning that
additional flag field bits would only be assigned, when appropriate additional flag field bits would only be assigned, when appropriate
as indicated above, to protocols with a store-and-forward nature as indicated above, to protocols with a store-and-forward nature or
(other than DNS) or otherwise not subsumed into a point-to-point otherwise not subsumed into a point-to-point paradigm.
paradigm.
3.5 The KEY Algorithm Number and the MD5/RSA Algorithm 3.5 The KEY Algorithm Number and the MD5/RSA Algorithm
This octet is the key algorithm parallel to the same field for the This octet is the key algorithm parallel to the same field for the
SIG resource. The MD5/RSA algorithm described in this draft is SIG resource. The MD5/RSA algorithm described in this draft is
number 1. Numbers 2 through 252 are available for assignment should number 1. Numbers 2 through 252 are available for assignment should
sufficient reason arise. However, the designation of a new algorithm sufficient reason arise. However, the designation of a new algorithm
could have a major impact on interoperability and requires an IETF could have a major impact on interoperability and requires an IETF
standards action. Number 254 is reserved for private use and will standards action. Number 254 is reserved for private use and will
never be assigned a specific algorithm. For number 254, the public never be assigned a specific algorithm. For number 254, the public
key area shown in the packet diagram above will actually begin with key area shown in the packet diagram above will actually begin with
an Object Identifier (OID) indicating the private algorithm in use an Object Identifier (OID) indicating the private algorithm in use
and the remainder of the area is whatever is required by that and the remainder of the area is whatever is required by that
algorithm. Number 253 is reserved as the "expiration date algorithm" algorithm. Number 253 is reserved as the "expiration date algorithm"
for use where the expiration date or other labeling fields of SIGs for use where the expiration date or other labeling fields of SIGs
are desired without any actual security. It is anticipated that this are desired without any actual security. It is anticipated that this
algorithm will only be used in connection with DNS dynamic update. algorithm will only be used in connection with some modes of DNS
For number 253, the public key area is null. Values 0 and 255 are dynamic update. For number 253, the public key area is null. Values
reserved. 0 and 255 are reserved.
If the no key bit is zero and the algorithm field is 1, indicating If the type field does not have the "no key" value and the algorithm
the MD5/RSA algorithm, the public key field is structured as follows: field is 1, indicating the MD5/RSA algorithm, the public key field is
structured as follows:
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pub exp length| public key exponent / | pub exp length| public key exponent /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| / | /
+- modulus / +- modulus /
| / | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
skipping to change at page 17, line 7 skipping to change at page 17, line 16
variable length unsigned integer. Its length in octets is variable length unsigned integer. Its length in octets is
represented as one octet if it is in the range of 1 to 255 and by a represented as one octet if it is in the range of 1 to 255 and by a
zero octet followed by a two octet unsigned length if it is longer zero octet followed by a two octet unsigned length if it is longer
than 255 bytes. The public key modulus field is a multiprecision than 255 bytes. The public key modulus field is a multiprecision
unsigned integer. The length of the modulus can be determined from unsigned integer. The length of the modulus can be determined from
the RDLENGTH and the preceding RDATA fields including the exponent. the RDLENGTH and the preceding RDATA fields including the exponent.
Leading zero bytes are prohibited in the exponent and modulus. Leading zero bytes are prohibited in the exponent and modulus.
3.6 Interaction of Flags, Algorithm, and Protocol Bytes 3.6 Interaction of Flags, Algorithm, and Protocol Bytes
Various combinations of the no-key bit, algorithm byte, protocol Various combinations of the no-key type value, algorithm byte,
byte, and any protocol indicating flags (such as the reserved IPSEC protocol byte, and any protocol indicating flags (such as the
flag) are possible. (Note that the zone flag bit being on or the reserved IPSEC flag) are possible. (Note that the zone flag bit
signatory field being non-zero is effectively a DNS protocol flag being on or the signatory field being non-zero is effectively a DNS
on.) The meaning of these combinations is indicated below: protocol flag on.) The meaning of these combinations is indicated
below:
NK = no key flag NK = no key type value
AL = algorithm byte AL = algorithm byte
PR = protocols indicated by protocol byte or protocol flags PR = protocols indicated by protocol byte or protocol flags
x represents any valid non-zero value(s). x represents any valid non-zero value(s).
AL PR NK Meaning AL PR NK Meaning
0 0 0 Illegal, claims key but has bad algorithm field. 0 0 0 Illegal, claims key but has bad algorithm field.
0 0 1 Specifies total lack of security for owner. 0 0 1 Specifies total lack of security for owner.
0 x 0 Illegal, claims key but has bad algorithm field. 0 x 0 Illegal, claims key but has bad algorithm field.
0 x 1 Specified protocols insecure, others may be secure. 0 x 1 Specified protocols insecure, others may be secure.
skipping to change at page 17, line 46 skipping to change at page 18, line 11
An explicit request for KEY RRs does not cause any special additional An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG information processing except, of course, for the corresponding SIG
RR from a security aware server. RR from a security aware server.
Security aware DNS servers will include KEY RRs as additional Security aware DNS servers will include KEY RRs as additional
information in responses where appropriate including the following: information in responses where appropriate including the following:
(1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone (1) On the retrieval of NS RRs, the zone key KEY RR(s) for the zone
served by these name servers MUST be included as additional served by these name servers MUST be included as additional
information. There will always be at least one such KEY RR in a information. There will always be at least one such KEY RR in a
secure zone, even if it has the no-key bit on to indicate that the secure zone, even if it has the no-key type value to indicate that
subzone is insecure. If not all additional information will fit, the the subzone is insecure. If not all additional information will fit,
KEY RR(s) have higher priority than type A or AAAA glue RRs. If such the KEY RR(s) have higher priority than type A or AAAA glue RRs. If
a KEY RR does not fit on a retrieval, the retrieval must be such a KEY RR does not fit on a retrieval, the retrieval must be
considered truncated. considered truncated.
(2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) will (2) On retrieval of type A or AAAA RRs, the end entity KEY RR(s) will
be included. On inclusion of A or AAAA RRs as additional be included. On inclusion of A or AAAA RRs as additional
information, their KEY RRs will also be included but with lower information, their KEY RRs will also be included but with lower
priority than the relevant A or AAAA RRs. priority than the relevant A or AAAA RRs.
3.8 File Representation of KEY RRs 3.8 File Representation of KEY RRs
KEY RRs may appear as lines in a zone data file. KEY RRs may appear as lines in a zone data master file.
The flag field, protocol, and algorithm number octets are then The flag field, protocol, and algorithm number octets are then
represented as unsigned integers. Note that if the "no key" flag is represented as unsigned integers. Note that if the type field has
on in the flags or the algorithm specified is 253, nothing appears the "no key" value or the algorithm specified is 253, nothing appears
after the algorithm octet. after the algorithm octet.
The remaining public key portion is represented in base 64 (see The remaining public key portion is represented in base 64 (see
Appendix) and may be divided up into any number of white space Appendix) and may be divided up into any number of white space
separated substrings, down to single base 64 digits, which are separated substrings, down to single base 64 digits, which are
concatenated to obtain the full signature. These substrings can span concatenated to obtain the full signature. These substrings can span
lines using the standard parenthesis. lines using the standard parenthesis.
Note that the public key may have internal sub-fields but these do Note that the public key may have internal sub-fields but these do
not appear in the master file representation. For example, with not appear in the master file representation. For example, with
skipping to change at page 19, line 52 skipping to change at page 19, line 52
The value of the SIG RR type is 24. The value of the SIG RR type is 24.
The "type covered" is the type of the other RRs covered by this SIG. The "type covered" is the type of the other RRs covered by this SIG.
The algorithm number is an octet specifying the digital signature The algorithm number is an octet specifying the digital signature
algorithm used parallel to the algorithm octet for the KEY RR. The algorithm used parallel to the algorithm octet for the KEY RR. The
MD5/RSA algorithm described in this draft is number 1. Numbers 2 MD5/RSA algorithm described in this draft is number 1. Numbers 2
through 252 are available for assignment should sufficient reason through 252 are available for assignment should sufficient reason
arise to allocate them. However, the designation of a new algorithm arise to allocate them. However, the designation of a new algorithm
could have a major impact on the interoperability of the global DNS could have a major impact on the interoperability of the global DNS
systems and requires an IETF standards action. Number 254 is system and requires an IETF standards action. Number 254 is reserved
reserved for private use and will not be assigned a specific for private use and will not be assigned a specific algorithm. For
algorithm. For number 254, the "signature" area shown above will number 254, the "signature" area shown above will actually begin with
actually begin with an Object Identifier (OID) indicating the private an Object Identifier (OID) indicating the private algorithm in use
algorithm in use and the remainder of the signature area is whatever and the remainder of the signature area is whatever is required by
is required by that algorithm. Number 253, known as the "expiration that algorithm. Number 253, known as the "expiration date
date" algorithm, is used when the expiration date other non-signature algorithm", is used when the expiration date or other non-signature
fields of the SIG are desired without any actual security. It is fields of the SIG are desired without any actual security. It is
anticipated that this algorithm will only be used in connection with anticipated that this algorithm will only be used in connection with
DNS dynamic update. For number 253, the signature field will be some modes of DNS dynamic update. For number 253, the signature
null. Values 0 and 255 are reserved. field will be null. Values 0 and 255 are reserved.
The "labels" octet is an unsigned count of how many labels there are The "labels" octet is an unsigned count of how many labels there are
in the original SIG RR owner name not counting the null label for in the original SIG RR owner name not counting the null label for
root and not counting any initial "*" for a wildcard. If a secured root and not counting any initial "*" for a wildcard. If a secured
retrieval is the result of wild card substitution, it is necessary retrieval is the result of wild card substitution, it is necessary
for the resolver to use the original form of the name in verifying for the resolver to use the original form of the name in verifying
the digital signature. This field helps optimize the determination the digital signature. This field helps optimize the determination
of the original form thus reducing the effort in authenticating of the original form thus reducing the effort in authenticating
signed data. signed data.
skipping to change at page 22, line 11 skipping to change at page 22, line 11
type covered with the same owner name and class as the SIG RR in type covered with the same owner name and class as the SIG RR in
canonical form and order. How this data sequence is processed into canonical form and order. How this data sequence is processed into
the signature is algorithm dependent. the signature is algorithm dependent.
For purposes of DNS security, the canonical form for an RR is the RR For purposes of DNS security, the canonical form for an RR is the RR
with domain names (1) fully expanded (no name compression via with domain names (1) fully expanded (no name compression via
pointers), (2) all domain name letters set to lower case, and (3) the pointers), (2) all domain name letters set to lower case, and (3) the
original TTL substituted for the current TTL. original TTL substituted for the current TTL.
For purposes of DNS security, the canonical order for RRs is to sort For purposes of DNS security, the canonical order for RRs is to sort
them in ascending order by name, then by type, as left justified them in ascending order by name, as left justified unsigned octet
unsigned octet sequences in network (transmission) order where a sequences in network (transmission) order where a missing octet sorts
missing octet sorts before a zero octet. (See also ordering before a zero octet. (See also ordering discussion in Section 5.1.)
discussion in Section 5.1.) Within any particular name they are Within any particular name they are similarly sorted by type and then
similarly sorted by type and then RDATA as a left justified unsigned RDATA as a left justified unsigned octet sequence. EXCEPT that the
octet sequence. EXCEPT that the type SIG RR(s) covering any type SIG RR(s) covering any particular type appear immediately after
particular type appear immediately after the other RRs of that type. the other RRs of that type. (This special consideration for SIG
(This special consideration for SIG RR(s) in ordering really only RR(s) in ordering really only applies to calculating the AXFR SIG RR
applies to calculating the AXFR SIG RR as explained in section 4.1.3 as explained in section 4.1.3 below.) Thus if at name a.b there are
below.) Thus if at name a.b there are two A RRs and one KEY RR, two A RRs and one KEY RR, their order with SIGs for concatenating the
their order with SIGs for concatenating the "data" to be signed would "data" to be signed would be as follows:
be as follows:
a.b. A .... a.b. A ....
a.b. A .... a.b. A ....
a.b. SIG A ... a.b. SIG A ...
a.b. KEY ... a.b. KEY ...
a.b. SIG KEY ... a.b. SIG KEY ...
SIGs covering type ANY should not be included in a zone. SIGs covering type ANY should not be included in a zone.
4.1.2 MD5/RSA Algorithm Signature Calculation 4.1.2 MD5/RSA Algorithm Signature Calculation
skipping to change at page 22, line 52 skipping to change at page 22, line 51
"n" is the public modulus of the signer's public key. 01, FF, and 00 "n" is the public modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. "prefix" is are fixed octets of the corresponding hexadecimal value. "prefix" is
the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1, the ASN.1 BER MD5 algorithm designator prefix specified in PKCS1,
that is, that is,
hex 3020300c06082a864886f70d020505000410 [NETSEC]. hex 3020300c06082a864886f70d020505000410 [NETSEC].
This prefix is included to make it easier to use RSAREF or similar This prefix is included to make it easier to use RSAREF or similar
packages. The FF octet is repeated the maximum number of times such packages. The FF octet is repeated the maximum number of times such
that the value of the quantity being exponentiated is one octet that the value of the quantity being exponentiated is one octet
shorter than the value of n. shorter than the value of n.
The above specifications are Public Key Cryptographic Standard #1 (The above specifications are Public Key Cryptographic Standard #1
[PKCS1]. [PKCS1].)
The size of n, including most and least significant bits (which will The size of n, including most and least significant bits (which will
be 1) SHALL be not less than 512 bits and not more than 2552 bits. n be 1) SHALL be not less than 512 bits and not more than 2552 bits. n
and e SHOULD be chosen such that the public exponent is small. and e SHOULD be chosen such that the public exponent is small.
Leading zeros bytes are not permitted in the MD5/RSA algorithm Leading zeros bytes are not permitted in the MD5/RSA algorithm
signature. signature.
A public exponent of 3 minimizes the effort needed to decode a A public exponent of 3 minimizes the effort needed to decode a
signature. Use of 3 as the public exponent may be weak for signature. Use of 3 as the public exponent may be weak for
confidentiality uses since, if the same data can be collected confidentiality uses since, if the same data can be collected
skipping to change at page 24, line 26 skipping to change at page 24, line 26
data = full response (less final transaction SIG) | full query data = full response (less final transaction SIG) | full query
Verification of the transaction SIG (which is signed by the server Verification of the transaction SIG (which is signed by the server
host key, not the zone key) by the requesting resolver shows that the host key, not the zone key) by the requesting resolver shows that the
query and response were not tampered with in transit, that the query and response were not tampered with in transit, that the
response corresponds to the intended query, and that the response response corresponds to the intended query, and that the response
comes from the queried server. comes from the queried server.
A DNS request may be optionally signed by including one or more SIGs A DNS request may be optionally signed by including one or more SIGs
at the end of the the query. Such SIGs are identified by having a at the end of the query. Such SIGs are identified by having a "type
"type covered" field of zero. They sign the preceding DNS request covered" field of zero. They sign the preceding DNS request message
message including DNS header but not including any preceding request including DNS header but not including any preceding request SIGs.
SIGs. Such request SIGs are included in the "data" used to form any Such request SIGs are included in the "data" used to form any
optional response transaction SIG. optional response transaction SIG.
WARNING: Request SIGs are unnecessary for currently defined queries WARNING: Request SIGs are unnecessary for currently defined queries
and will cause almost all existing DNS servers to completely ignore a and will cause almost all existing DNS servers to completely ignore a
query. However, such SIGs may be need to authenticate future DNS query. However, such SIGs may be need to authenticate future DNS
secure dynamic update or other requests. secure dynamic update or other requests.
4.2 SIG RRs in the Construction of Responses 4.2 SIG RRs in the Construction of Responses
Security aware DNS servers MUST, for every authoritative RR the query Security aware DNS servers MUST, for every authoritative RR the query
will return, attempt to send the available SIG RRs which authenticate will return, attempt to send the available SIG RRs which authenticate
the requested RR. The following rules apply to the inclusion of SIG the requested RR. The following rules apply to the inclusion of SIG
RRs in responses: RRs in responses:
1. when an RR is placed in a response, its SIG RR has a higher 1. when an RR is placed in a response, its SIG RR has a higher
priority for inclusion than other RRs that may need to be priority for inclusion than other RRs that may need to be
included. If space does not permit its inclusion, the response included. If space does not permit its inclusion, the response
MUST be considered truncated except as provided in 2 below. MUST be considered truncated except as provided in 2 below.
2. when a SIG RR is present for an additional information section RR, 2. when a SIG RR is present in the zone for an additional information
the response MUST NOT be considered truncated merely because space section RR, the response MUST NOT be considered truncated merely
does not permit the inclusion of its SIG RR. because space does not permit the inclusion of its SIG RR.
SIGs to authenticate non-authoritative data (glue records and NS RRs 3. SIGs to authenticate non-authoritative data (glue records and NS
for subzones) are unnecessary and MUST not be sent. Note that KEYs RRs for subzones) are unnecessary and MUST NOT be sent. (Note
for subzones are authoritative in a superzone. that KEYs for subzones are controlling in a superzone so the
superzone's signature on the KEY MUST be included (unless the KEY
was additional information).)
If a SIG covers any RR that would be in the answer section of the 4. If a SIG covers any RR that would be in the answer section of the
response, its automatic inclusion MUST be the answer section. If it response, its automatic inclusion MUST be the answer section. If
covers an RR that would appear in the authority section, its it covers an RR that would appear in the authority section, its
automatic inclusion MUST be in the authority section. If it covers automatic inclusion MUST be in the authority section. If it
an RR that would appear in the additional information section it MUST covers an RR that would appear in the additional information
appear in the additional information section. This is a change in section it MUST appear in the additional information section.
the existing standard which contemplates only NS and SOA RRs in the This is a change in the existing standard which contemplates only
authority section. NS and SOA RRs in the authority section.
Optionally, DNS transactions may be authenticated by a SIG RR at the 5. Optionally, DNS transactions may be authenticated by a SIG RR at
end of the response in the additional information section (Section the end of the response in the additional information section
4.1.4). Such SIG RRs are signed by the DNS server originating the (Section 4.1.4). Such SIG RRs are signed by the DNS server
response. Although the signer field MUST be the name of the originating the response. Although the signer field MUST be the
originating server host, the owner name, class, TTL, and original name of the originating server host, the owner name, class, TTL,
TTL, are meaningless. The class and TTL fields SHOULD be zero. To and original TTL, are meaningless. The class and TTL fields
conserve space, the owner name SHOULD be root (a single zero octet). SHOULD be zero. To conserve space, the owner name SHOULD be root
If transaction authentication is desired, that SIG RR must be (a single zero octet). If transaction authentication is desired,
considered higher priority for inclusion than any other RR in the that SIG RR must be considered higher priority for inclusion than
response. any other RR in the response.
4.3 Processing Responses and SIG RRs 4.3 Processing Responses and SIG RRs
The following rules apply to the processing of SIG RRs included in a The following rules apply to the processing of SIG RRs included in a
response: response:
1. a security aware resolver that receives a response from what it 1. a security aware resolver that receives a response from what it
believes to be a security aware server via a secure communication believes to be a security aware server via a secure communication
with the AD bit (see Section 6.1) set, MAY choose to accept the with the AD bit (see Section 6.1) set, MAY choose to accept the
RRs as received without verifying the SIG RRs. RRs as received without verifying the SIG RRs.
skipping to change at page 28, line 22 skipping to change at page 28, line 22
The nonexistence of a name in a zone is indicated by the NXT ("next") The nonexistence of a name in a zone is indicated by the NXT ("next")
RR for a name interval containing the nonexistent name. A NXT RR and RR for a name interval containing the nonexistent name. A NXT RR and
its SIG are returned in the authority section, along with the error, its SIG are returned in the authority section, along with the error,
if the server is security aware. The same is true for a non-existent if the server is security aware. The same is true for a non-existent
type under an existing name. This is a change in the existing type under an existing name. This is a change in the existing
standard which contemplates only NS and SOA RRs in the authority standard which contemplates only NS and SOA RRs in the authority
section. NXT RRs will also be returned if an explicit query is made section. NXT RRs will also be returned if an explicit query is made
for the NXT type. for the NXT type.
The existence of a complete set of NXT records in a zone means that The existence of a complete set of NXT records in a zone means that
any query for any name and type to a security aware server serving any query for any name and any type to a security aware server
the zone will result in an reply containing at least one signed RR. serving the zone will always result in an reply containing at least
one signed RR.
NXT RRs do not appear in zone master files since they can be derived NXT RRs do not appear in zone master files since they can be derived
from the rest of the zone. from the rest of the zone.
5.1 The NXT Resource Record 5.1 The NXT Resource Record
The NXT resource record is used to securely indicate that RRs with an The NXT resource record is used to securely indicate that RRs with an
owner name in a certain name interval do not exist in a zone and to owner name in a certain name interval do not exist in a zone and to
indicate what zone signed RR types are present for an existing name. indicate what zone signed RR types are present for an existing name.
skipping to change at page 28, line 46 skipping to change at page 28, line 47
means that generally no name between its owner name and the name in means that generally no name between its owner name and the name in
its RDATA area exists and that no other zone signed types exist under its RDATA area exists and that no other zone signed types exist under
its owner name. This implies a canonical ordering of all domain its owner name. This implies a canonical ordering of all domain
names in a zone. names in a zone.
The ordering is to sort labels as unsigned left justified octet The ordering is to sort labels as unsigned left justified octet
strings where the absence of a octet sorts before a zero octet and strings where the absence of a octet sorts before a zero octet and
upper case letters are treated as lower case letters. Names are then upper case letters are treated as lower case letters. Names are then
sorted by sorting on the highest level label and then, within those sorted by sorting on the highest level label and then, within those
names with the same highest level label by the next lower label, etc. names with the same highest level label by the next lower label, etc.
Since we are talking about a zone, the zone name itself always exists down to leaf node labels. Since we are talking about a zone, the
and all other names are the zone name with some prefix of lower level zone name itself always exists and all other names are the zone name
labels. Thus the zone name itself always sorts first. with some prefix of lower level labels. Thus the zone name itself
always sorts first.
There is a problem with the last NXT in a zone as it wants to have an There is a problem with the last NXT in a zone as it wants to have an
owner name which is the last existing name in sort order, which is owner name which is the last existing name in sort order, which is
easy, but it is not obvious what name to put in its RDATA to indicate easy, but it is not obvious what name to put in its RDATA to indicate
the entire remainder of the name space. This is handled by treating the entire remainder of the name space. This is handled by treating
the name space as circular and putting the zone name in the RDATA of the name space as circular and putting the zone name in the RDATA of
the last NXT in a zone. the last NXT in a zone.
There are special considerations due to interaction with wildcards as There are special considerations due to interaction with wildcards as
explained below. explained below.
skipping to change at page 31, line 6 skipping to change at page 31, line 10
The existence of one or more wildcard RRs covering a name interval The existence of one or more wildcard RRs covering a name interval
makes it possible for a malicious server to hide any more makes it possible for a malicious server to hide any more
specifically named RRs in the internal. The server can just falsely specifically named RRs in the internal. The server can just falsely
return the wildcard match NXT instead of the more specifically named return the wildcard match NXT instead of the more specifically named
RRs. If there is a zone wide wildcard, there will be an NXT RR whose RRs. If there is a zone wide wildcard, there will be an NXT RR whose
owner name is the wild card and whose RDATA is the zone name. In owner name is the wild card and whose RDATA is the zone name. In
this case a server could conceal the existence of any more specific this case a server could conceal the existence of any more specific
RRs in the zone. (It would be possible to design a more strict NXT RRs in the zone. (It would be possible to design a more strict NXT
feature which would eliminate this possibility. But it would be more feature which would eliminate this possibility. But it would be more
complex and might be so constraining as to make any dynamic update complex and might be so constraining as to make any dynamic update
feature that could create new names very difficult.) feature very difficult.)
What name should be put into the RDATA of an NXT RR with an owner What name should be put into the RDATA of an NXT RR with an owner
name that is within a wild card scope? Since the "next" existing name that is within a wild card scope? Since the "next" existing
name will be one that matches the wild card, the wild card name name will be one that matches the wild card, the wild card name
should be used. Inclusion of such NXTs for names interior to a wild should be used. Inclusion of such NXTs for names interior to a wild
card scope is optional. card scope is optional.
5.5 Blocking NXT Pseudo-Zone Transfers 5.5 Blocking NXT Pseudo-Zone Transfers
In a secure zone, a resolver can query for the initial NXT associated In a secure zone, a resolver can query for the initial NXT associated
skipping to change at page 31, line 32 skipping to change at page 31, line 36
perhaps defeat attempts to administratively block zone transfers. perhaps defeat attempts to administratively block zone transfers.
If there are any wildcards, this NXT walking technique will not find If there are any wildcards, this NXT walking technique will not find
any more specific RR names in the part of the name space the wildcard any more specific RR names in the part of the name space the wildcard
covers. By doing explicit retrievals for wildcard names, a resolver covers. By doing explicit retrievals for wildcard names, a resolver
could determine what intervals are covered by wildcards but still could determine what intervals are covered by wildcards but still
could not, with these techniques, find any names inside such could not, with these techniques, find any names inside such
intervals except by trying every name. intervals except by trying every name.
If it is desired to block NXT walking, the recommended method is to If it is desired to block NXT walking, the recommended method is to
add a zone wide wildcard of the KEY type with the no key bit on and add a zone wide wildcard of the KEY type with the no-key type value
with no type (zone, entity, or user) bit on. This will cause there and with no type (zone, entity, or user) bit on. This will cause
to be one zone covering NXT RR and leak no information about what there to be one zone covering NXT RR and leak no information about
real names exist in the zone. This protection from pseudo-zone what real names exist in the zone. This protection from pseudo-zone
transfers is bought at the expense of eliminating the data origin transfers is bought at the expense of eliminating the data origin
authentication of the non-existence of names that NXT RRs can authentication of the non-existence of names that NXT RRs can
provide. If an entire zone is covered by a wildcard, a malicious provide. If an entire zone is covered by a wildcard, a malicious
server can return an RR produced by matching the resulting wildcard server can return an RR produced by matching the resulting wildcard
NXT and can thus hide all the real data and delegations with more NXT and can thus hide all the real data and delegations with more
specific names in the zone. specific names in the zone.
5.6 Special Considerations at Delegation Points 5.6 Special Considerations at Delegation Points
A name (other than root) which is the head of a zone also appears as A name (other than root) which is the head of a zone also appears as
skipping to change at page 35, line 9 skipping to change at page 35, line 9
is as follows: is as follows:
pubkey name flags protocol algorithm key-data pubkey name flags protocol algorithm key-data
for a public key. "name" is the owner name (if the line is for a public key. "name" is the owner name (if the line is
translated into a KEY RR). Flags indicates the type of key and is translated into a KEY RR). Flags indicates the type of key and is
the same as the flag octet in the KEY RR. Protocol and algorithm the same as the flag octet in the KEY RR. Protocol and algorithm
also have the same meaning as they do in the KEY RR. The material also have the same meaning as they do in the KEY RR. The material
after the algorithm is algorithm dependent and, for private after the algorithm is algorithm dependent and, for private
algorithms (algorithm 254), starts with the algorithm's identifying algorithms (algorithm 254), starts with the algorithm's identifying
OID. If the "no key" bit is on in flags or the algorithm is OID. If the "no key" type value is set in flags or the algorithm is
specified as 253, then the key-data after algorithm is null. It is specified as 253, then the key-data after algorithm is null. It is
treated as an octet stream and encoded in base 64 (see Appendix). treated as an octet stream and encoded in base 64 (see Appendix).
A file of keys for cross certification or other purposes can be A file of keys for cross certification or other purposes can be
configured though the keyfile directive as follows: configured though the keyfile directive as follows:
keyfile filename keyfile filename
The file looks like a master file except that it can only contain KEY The file looks like a master file except that it can only contain KEY
and SIG RRs with the SIGs signed under a key configured with the and SIG RRs with the SIGs signed under a key configured with the
skipping to change at page 36, line 6 skipping to change at page 36, line 6
traversed from a starting point to any secure zone it can reach. In traversed from a starting point to any secure zone it can reach. In
general, the lower such a distance number is, the greater the general, the lower such a distance number is, the greater the
confidence in the data. Data configured via a boot file directive confidence in the data. Data configured via a boot file directive
should be given a distance number of zero. Should a query encounter should be given a distance number of zero. Should a query encounter
different data for the same query with different distance values, different data for the same query with different distance values,
that with a larger value should be ignored. that with a larger value should be ignored.
A security conscious resolver should completely refuse to step from a A security conscious resolver should completely refuse to step from a
secure zone into a non-secure zone unless the non-secure zone is secure zone into a non-secure zone unless the non-secure zone is
certified to be non-secure, or only experimentally secure, by the certified to be non-secure, or only experimentally secure, by the
presence of an authenticated KEY RR for the non-secure zone with a no presence of an authenticated KEY RR for the non-secure zone with the
key flag or algorithm 253 or the presence of a KEY RR with the no-key type value or the presence of a KEY RR with the experimental
experimental bit set. Otherwise the resolver is probably getting bit set. Otherwise the resolver is getting bogus or spoofed data.
bogus or spoofed data.
If legitimate non-secure zones are encountered in traversing the DNS If legitimate non-secure zones are encountered in traversing the DNS
tree, then no zone can be trusted as secure that can be reached only tree, then no zone can be trusted as secure that can be reached only
via information from such non-secure zones. Since the non-secure zone via information from such non-secure zones. Since the non-secure zone
data could have been spoofed, the "secure" zone reach via it could be data could have been spoofed, the "secure" zone reach via it could be
counterfeit. The "distance" to data in such zones or zones reached counterfeit. The "distance" to data in such zones or zones reached
via such zones could be set to 512 or more as this exceeds the via such zones could be set to 512 or more as this exceeds the
largest possible distance through secure zones in the DNS. largest possible distance through secure zones in the DNS.
Nevertheless, continuing to apply secure checks within "secure" zones Nevertheless, continuing to apply secure checks within "secure" zones
reached via non-secure zones is a good practice and will, as a reached via non-secure zones is a good practice and will, as a
skipping to change at page 37, line 29 skipping to change at page 37, line 29
For most schemes, larger keys are more secure but slower. Given a For most schemes, larger keys are more secure but slower. Given a
small public exponent, verification (the most common operation) for small public exponent, verification (the most common operation) for
the MD5/RSA algorithm will vary roughly with the square of the the MD5/RSA algorithm will vary roughly with the square of the
modulus length, signing will vary with the cube of the modulus modulus length, signing will vary with the cube of the modulus
length, and key generation (the least common operation) will vary length, and key generation (the least common operation) will vary
with the fourth power of the modulus length. The current best with the fourth power of the modulus length. The current best
algorithms for factoring a modulus and breaking RSA security vary algorithms for factoring a modulus and breaking RSA security vary
roughly with the 1.6 power of the modulus itself. Thus going from a roughly with the 1.6 power of the modulus itself. Thus going from a
640 bit modulus to a 1280 bit modulus only increases the verification 640 bit modulus to a 1280 bit modulus only increases the verification
time by a factor of 4 but increases the work factor of breaking the time by a factor of 4 but increases the work factor of breaking the
key by over 2^900. An upper bound of 2552 bit has been established key by over 2^900. An upper bound of 2552 bits has been established
for the MD5/RSA DNS security algorithm for interoperability purposes. for the MD5/RSA DNS security algorithm for interoperability purposes.
However, larger keys increase the size of the KEY and SIG RRs. This However, larger keys increase the size of the KEY and SIG RRs. This
increases the chance of DNS UDP packet overflow and the possible increases the chance of DNS UDP packet overflow and the possible
necessity for using higher overhead TCP in responses. necessity for using higher overhead TCP in responses.
The recommended minimum RSA algorithm modulus size, 640 bits, is The recommended minimum RSA algorithm modulus size, 640 bits, is
believed by the authors to be secure at this time but high level believed by the authors to be secure at this time but high level
zones in the DNS tree may wish to set a higher minimum, perhaps 1000 zones in the DNS tree may wish to set a higher minimum, perhaps 1000
bits, for security reasons. (Since the United States National bits, for security reasons. (Since the United States National
skipping to change at page 38, line 6 skipping to change at page 38, line 6
For a key used only to secure data and not to secure other keys, 640 For a key used only to secure data and not to secure other keys, 640
bits should be adequate. bits should be adequate.
7.2 Key Storage 7.2 Key Storage
It is recommended that zone private keys and the zone file master It is recommended that zone private keys and the zone file master
copy be kept and used in off-line non-network connected physically copy be kept and used in off-line non-network connected physically
secure machines only. Periodically an application can be run to add secure machines only. Periodically an application can be run to add
authentication to a zone by adding SIG and NXT RRs and adding no-key authentication to a zone by adding SIG and NXT RRs and adding no-key
KEY RRs for subzones where a real KEY RR is not provided. Then the type KEY RRs for subzones where a real KEY RR is not provided. Then
augmented file can be transferred, perhaps by sneaker-net, to the the augmented file can be transferred, perhaps by sneaker-net, to the
networked zone primary server machine. networked zone primary server machine.
The idea is to have a one way information flow to the network to The idea is to have a one way information flow to the network to
avoid the possibility of tampering from the network. Keeping the avoid the possibility of tampering from the network. Keeping the
zone master file on-line on the network and simply cycling it through zone master file on-line on the network and simply cycling it through
an off-line signer does not do this. The on-line version could still an off-line signer does not do this. The on-line version could still
be tampered with if the host it resides on is compromised. For be tampered with if the host it resides on is compromised. For
maximum security, the master copy of the zone file should be off net maximum security, the master copy of the zone file should be off net
and should not be updated based on an unsecured network mediated and should not be updated based on an unsecured network mediated
communication. communication.
skipping to change at page 39, line 30 skipping to change at page 39, line 30
It is recommended that signature lifetime be a small multiple of the It is recommended that signature lifetime be a small multiple of the
TTL but not less than a reasonable re-signing interval. TTL but not less than a reasonable re-signing interval.
7.6 Root 7.6 Root
It should be noted that in DNS the root is a zone unto itself. Thus It should be noted that in DNS the root is a zone unto itself. Thus
the root zone key should only be seen signing itself or signing RRs the root zone key should only be seen signing itself or signing RRs
with names one level below root, such as .aq, .edu, or .arpa. with names one level below root, such as .aq, .edu, or .arpa.
Implementations MAY reject as bogus any purported root signature of Implementations MAY reject as bogus any purported root signature of
records with a name more than one level below root. records with a name more than one level below root. The root zone
contains the root KEY RR signed by a SIG RR under the root key
itself.
8. Conformance 8. Conformance
Several levels of server and resolver conformance are defined. Several levels of server and resolver conformance are defined.
8.1 Server Conformance 8.1 Server Conformance
Two levels of server conformance are defined as follows: Two levels of server conformance are defined as follows:
Minimal server compliance is the ability to store and retrieve Minimal server compliance is the ability to store and retrieve
skipping to change at page 42, line 36 skipping to change at page 42, line 36
[RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16 [RFC1321] - The MD5 Message-Digest Algorithm, R. Rivest, April 16
1992. 1992.
[RFC1530] - Principles of Operation for the TPC.INT Subdomain: [RFC1530] - Principles of Operation for the TPC.INT Subdomain:
General Principles and Policy, C. Malamud, M. Rose, October 6 1993. General Principles and Policy, C. Malamud, M. Rose, October 6 1993.
[RFC1750] - Randomness Requirements for Security, D. Eastlake, S. [RFC1750] - Randomness Requirements for Security, D. Eastlake, S.
Crocker, J. Schiller, December 1994. Crocker, J. Schiller, December 1994.
[RFC1825] - Security Architecture for the Internet Protocol, R. [RFC1825] - Security Architecture for the Internet Protocol, R.
Atkinson, Atkinson, August 9 1995.
August 9 1995.
[RSA FAQ] - RSADSI Frequently Asked Questions periodic posting. [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
Authors Addresses Authors Addresses
Donald E. Eastlake, 3rd Donald E. Eastlake, 3rd
CyberCash, Inc. CyberCash, Inc.
318 Acton Street 318 Acton Street
Carlisle, MA 01741 USA Carlisle, MA 01741 USA
skipping to change at page 43, line 26 skipping to change at page 43, line 26
Charles W. Kaufman Charles W. Kaufman
Iris Associates Iris Associates
1 Technology Park Drive 1 Technology Park Drive
Westford, MA 01886 USA Westford, MA 01886 USA
Telephone: +1 508-392-5276 Telephone: +1 508-392-5276
EMail: charlie_kaufman@iris.com EMail: charlie_kaufman@iris.com
Expiration and File Name Expiration and File Name
This draft expires 27 June 1996. This draft expires 8 July 1996.
Its file name is draft-ietf-dnssec-secext-07.txt. Its file name is draft-ietf-dnssec-secext-08.txt.
Appendix: Base 64 Encoding Appendix: Base 64 Encoding
The following encoding technique is taken from RFC 1521 by N. Borenstein The following encoding technique is taken from RFC 1521 by N. Borenstein
and N. Freed. It is reproduced here in an edited form for convenience. and N. Freed. It is reproduced here in an edited form for convenience.
A 65-character subset of US-ASCII is used, enabling 6 bits to be A 65-character subset of US-ASCII is used, enabling 6 bits to be
represented per printable character. (The extra 65th character, "=", represented per printable character. (The extra 65th character, "=",
is used to signify a special processing function.) is used to signify a special processing function.)
 End of changes. 46 change blocks. 
147 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/