idnits 2.17.1 draft-yao-dnsext-msig-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: To provide secret key authentication, we use a new RR type whose mnemonic is MSIG and whose type code is X. MSIG is a meta-RR and MUST not be cached. MSIG RRs are used for authentication between DNS entities. MSIG RRs are dynamically computed to cover a particular DNS transaction and are not DNS RRs in the usual sense. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a server has generated a response to a signed request, it signs the response using the same algorithm and key. The server MUST not generate a signed response to an unsigned request. The digest components are: == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When a client receives a response from a server and expects to see a MSIG, it first checks if the MSIG RR is present in the response. Otherwise, the response is treated as having a format error and discarded. The client then extracts the MSIG, adjusts the ARCOUNT, and calculates the keyed digest in the same way as the server. If the MSIG does not validate, that response MUST be discarded, unless the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to verify the response as if it were a MSIG Error response, as specified in [4.3]. A message containing an unsigned MSIG record or a MSIG record which fails verification SHOULD not be considered an acceptable response; the client SHOULD log an error and continue to wait for a signed response until the request times out. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 367, but no explicit reference was found in the text == Unused Reference: 'RFC2136' is defined on line 370, but no explicit reference was found in the text == Unused Reference: 'RFC2671' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC2672' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC3597' is defined on line 380, but no explicit reference was found in the text == Unused Reference: 'RFC3743' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC5155' is defined on line 400, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2671 (Obsoleted by RFC 6891) ** Obsolete normative reference: RFC 2672 (Obsoleted by RFC 6672) ** Downref: Normative reference to an Informational RFC: RFC 3743 Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jiankang. Yao 3 Internet-Draft CNNIC 4 Intended status: Standards Track October 25, 2010 5 Expires: May 24, 2011 7 MSIG for Lightweight DNSSEC 8 draft-yao-dnsext-msig-01.txt 10 Abstract 12 DNSSEC is trying to be deployed everywhere. Many are afraid of 13 DNSSEC deployment, which are too heavy to be deployed. There is a 14 huge gap between the resources we need to deploy DNSSEC and the 15 benefits or security we can get from the DNSSEC. This document 16 proposes a lightweight DNSSEC mechanism to make the DNSSEC to be 17 deployed easily while getting the similar security with the heavy 18 DNSSEC. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 14, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. MSIG mechanism . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Using RKIQ as the trust measurement . . . . . . . . . . . . . 4 70 3.1. MSIG RR Format . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1.1. MSIG RR type . . . . . . . . . . . . . . . . . . . . . 4 72 3.1.2. MSIG Calculation . . . . . . . . . . . . . . . . . . . 4 73 3.1.3. Record Format . . . . . . . . . . . . . . . . . . . . 4 74 3.2. Protocol Operation . . . . . . . . . . . . . . . . . . . . 6 75 3.2.1. Effects of adding MSIG to outgoing message . . . . . . 6 76 3.2.2. MSIG processing on incoming messages . . . . . . . . . 6 77 3.2.3. MSIG Variables and Coverage . . . . . . . . . . . . . 6 78 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. MSIG generation on requests . . . . . . . . . . . . . . . 7 80 4.2. MSIG on Answers . . . . . . . . . . . . . . . . . . . . . 7 81 4.3. MSIG on MSIG Error returns . . . . . . . . . . . . . . . . 7 82 4.4. Server MSIG checks . . . . . . . . . . . . . . . . . . . . 7 83 4.5. Client processing of answer . . . . . . . . . . . . . . . 8 84 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 87 8. Change History . . . . . . . . . . . . . . . . . . . . . . . . 8 88 8.1. draft-yao-dnsext-msig: Version 00 . . . . . . . . . . . . 9 89 9. Normative References . . . . . . . . . . . . . . . . . . . . . 9 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 1. Introduction 94 DNSSEC (Domain Name System Security Extensions) [RFC4033] [RFC4034] 95 [RFC4035] has secured the communication between the root server and 96 the recursive resolver. [RFC4035] provides public key transaction 97 signatures to support this, but it needs to sign every resource 98 record. So for every resource record queried, a public key verifying 99 procedure is necessary. DNSSEC needs not only DS and DNSKEY resource 100 record but also, NSEC or NSEC3 and RRSIG to deploy DNSSEC. The size 101 of the DNSSEC signed zone can be easily be expanded to 3 or 5 times 102 of the original zone without enabled DNSSEC. DNSCurv proposal has 103 gotten some controversional discussion because it totally changed the 104 DNS packet and may change the DNS to the new stuff. TSIG is 105 lightweight, and provides both authentication and integrity checking, 106 but TSIG requires configuration of a shared secret, so it suffers 107 from a serious key distribution problem and can not be used for 108 server-server communications. This document specifies the new 109 mechanism which provides the message siganature (MSIG) between severs 110 and servers or between servers and resolvers. 112 1.1. Terminology 114 All the basic terms used in this specification are defined in the 115 documents [RFC1034], and [RFC1035]. In this document, there are two 116 kinds of resolvers: the stub resolver and the recursive resolver. In 117 this document, the resolver specially means the recursive resolver. 119 2. MSIG mechanism 121 This mechanisem will use the public key technology to make sure that 122 the dns query or response packet is authenticated and integirated. 123 There are RRSIG and NSEC (NSEC3) for every resource record [RFC1034] 124 and [RFC1035] in the crrent DNSSEC technology [RFC4033] [RFC4034] and 125 [RFC4035]. This document specifys that only DNSKEY and DS resource 126 records can have the RRSIGs. Other resource records such as MX, A 127 resource record will not need the RRSIG resource record. This make 128 the zone to expand only a little. This document defines a new 129 resource record called MSIG, which store the DNS message siganature. 130 The outgoing DNS message from one zone will use the zone's DNSKEY to 131 produce a keyed-hash siganature similar to producing of RRSIG. This 132 siganature will be the part of RDATA of the MSIG resource record. 133 The price of the DNSSEC deployment will be decreased as much as 134 possible. The recipient of the MSIG can use the public key to verify 135 the siganature to prove whether the DNS message is recived from the 136 proper sender and does not be tampered. Both the DNS query and 137 response can produce and bring the DNS siganature in the MSIG 138 resource record. 140 3. Using RKIQ as the trust measurement 142 3.1. MSIG RR Format 144 3.1.1. MSIG RR type 146 To provide secret key authentication, we use a new RR type whose 147 mnemonic is MSIG and whose type code is X. MSIG is a meta-RR and MUST 148 not be cached. MSIG RRs are used for authentication between DNS 149 entities. MSIG RRs are dynamically computed to cover a particular 150 DNS transaction and are not DNS RRs in the usual sense. 152 3.1.2. MSIG Calculation 154 As the MSIG RRs are related to one DNS request/response, there is no 155 value in storing or retransmitting them, thus the MSIG RR is 156 discarded once it has been used to authenticate a DNS message. The 157 only message digest algorithm specified in this document is same as 158 the specification in DNSSEC [RFC4033] [RFC4034] and [RFC4035]. Other 159 algorithms can be specified at a later date. This document will 160 follow the names and definitions of new algorithms registered with 161 IANA for DNSSEC. All multi-octet integers in the MSIG record are 162 sent in network byte order (see [RFC1035 2.3.2]). 164 3.1.3. Record Format 166 MSIG 168 The owner name will be in the form of msig_.example.com while the 169 example.com is the name of the apex of the zone if the msig is from 170 the DNS servers, the "resolver.resolver" or the resolver's domain 171 name if the msig is from the resolver. The TTL is zero, the class 172 can be any, and the RDATA has the following wire format 173 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Key Tag | Algorithm | reserved | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Signature Expiration | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Signature Inception | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 / / 183 / Signer's Name / 184 / / 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 / / 187 / Signature / 188 / / 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 3.1.3.1. The Key Tag Field 193 The Key Tag field contains the key tag value of the DNSKEY RR that 194 validates this signature, in network byte order. Appendix B explains 195 how to calculate Key Tag values of [RFC4034]. 197 3.1.3.2. The Algorithm Number Field 199 The Algorithm Number field identifies the cryptographic algorithm 200 used to create the signature. A list of DNSSEC algorithm types can 201 be found in Appendix A.1 of [RFC4034]. 203 3.1.3.3. The reserved Field 205 This field is for future use. 207 3.1.3.4. Signature Expiration and Inception Fields 209 The Signature Expiration and Inception fields specify a validity 210 period for the signature. The RRSIG record MUST NOT be used for 211 authentication prior to the inception date and MUST NOT be used for 212 authentication after the expiration date. The Signature Expiration 213 and Inception field values specify a date and time in the form of a 214 32-bit unsigned number of seconds elapsed since 1 January 1970 215 00:00:00 UTC, ignoring leap seconds, in network byte order. 217 3.2. Protocol Operation 219 3.2.1. Effects of adding MSIG to outgoing message 221 Once the outgoing message has been constructed, the keyed message 222 digest operation can be performed. The resulting message digest will 223 then be stored in a MSIG which is appended to the additional data 224 section (the ARCOUNT is incremented to reflect this). If the MSIG 225 record cannot be added without causing the message to be truncated, 226 the server MUST alter the response so that a MSIG can be included. 227 This response consists of only the question and a MSIG record, and 228 has the TC bit set and RCODE 0 (NOERROR). The client SHOULD at this 229 point retry the request using TCP (per [RFC1035 4.2.2]). 231 3.2.2. MSIG processing on incoming messages 233 If an incoming message contains a MSIG record, it MUST be the last 234 record in the additional section. Multiple MSIG records are not 235 allowed. If a MSIG record is present in any other position, the 236 packet is dropped and a response with RCODE 1 (FORMERR) MUST be 237 returned. Upon receipt of a message with a correctly placed MSIG RR, 238 the MSIG RR is copied to a safe location, removed from the DNS 239 Message, and decremented out of the DNS message header's ARCOUNT. At 240 this point the keyed message digest operation is performed. If the 241 algorithm name or key name is unknown to the recipient, or if the 242 message digests do not match, the whole DNS message MUST be 243 discarded. If the message is a query, a response with RCODE 9 244 (NOTAUTH) MUST be sent back to the originator with MSIG ERROR 17 245 (BADKEY) or MSIG ERROR 16 (BADSIG). If no key is available to sign 246 this message it MUST be sent unsigned (MAC size == 0 and empty MAC). 247 A message to the system operations log SHOULD be generated, to warn 248 the operations staff of a possible security incident in progress. 249 Care should be taken to ensure that logging of this type of event 250 does not open the system to a denial of service attack. 252 3.2.3. MSIG Variables and Coverage 254 A whole and complete DNS message in wire format, before the MSIG RR 255 has been added to the additional data section and before the DNS 256 Message Header's ARCOUNT field has been incremented to contain the 257 MSIG RR. If the message ID differs from the original message ID, the 258 original message ID is substituted for the message ID. This could 259 happen when forwarding a dynamic update request, for example. 261 4. Protocol Details 262 4.1. MSIG generation on requests 264 Client performs the message digest operation and appends a MSIG 265 record to the additional data section and transmits the request to 266 the server. The client MUST store the message digest from the 267 request while awaiting an answer. The digest components for a 268 request are: DNS Message (request) MSIG Variables (request) Note that 269 some older name servers will not accept requests with a nonempty 270 additional data section. Clients SHOULD only attempt signed 271 transactions with servers who are known to support MSIG and share 272 some secret key with the client -- so, this is not a problem in 273 practice. 275 4.2. MSIG on Answers 277 When a server has generated a response to a signed request, it signs 278 the response using the same algorithm and key. The server MUST not 279 generate a signed response to an unsigned request. The digest 280 components are: 282 Request MAC 283 DNS Message (response) 284 MSIG Variables (response) 286 4.3. MSIG on MSIG Error returns 288 When a server detects an error relating to the key or MAC, the server 289 SHOULD send back an unsigned error message (MAC size == 0 and empty 290 MAC). If an error is detected relating to the MSIG validity period, 291 the server SHOULD send back a signed error message. The digest 292 components are: 294 Request MAC (if the request MAC validated) 295 DNS Message (response) 296 MSIG Variables (response) 298 The reason that the request is not included in this digest in some 299 cases is to make it possible for the client to verify the error. If 300 the error is not a MSIG error the response MUST be generated as 301 specified in [4.2]. 303 4.4. Server MSIG checks 305 Upon receipt of a message, server will check if there is a MSIG RR. 306 If one exists, the server is REQUIRED to return a MSIG RR in the 307 response. The server MUST perform the following checks in the 308 following order, check KEY, check TIME values, check MAC. If a non- 309 forwarding server does not recognize the key used by the client, the 310 server MUST generate an error response with RCODE 9 (NOTAUTH) and 311 MSIG ERROR 17 (BADKEY). This response MUST be unsigned as specified 312 in [4.3]. The server SHOULD log the error. 314 4.5. Client processing of answer 316 When a client receives a response from a server and expects to see a 317 MSIG, it first checks if the MSIG RR is present in the response. 318 Otherwise, the response is treated as having a format error and 319 discarded. The client then extracts the MSIG, adjusts the ARCOUNT, 320 and calculates the keyed digest in the same way as the server. If 321 the MSIG does not validate, that response MUST be discarded, unless 322 the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to 323 verify the response as if it were a MSIG Error response, as specified 324 in [4.3]. A message containing an unsigned MSIG record or a MSIG 325 record which fails verification SHOULD not be considered an 326 acceptable response; the client SHOULD log an error and continue to 327 wait for a signed response until the request times out. 329 If an RCODE on a response is 9 (NOTAUTH), and the response MSIG 330 validates, and the MSIG key is different from the key used on the 331 request, then this is a KEY error. The client MAY retry the request 332 using the key specified by the server. This should never occur, as a 333 server MUST NOT sign a response with a different key than signed the 334 request. 336 5. IANA Considerations 338 TBD 340 6. Security Considerations 342 TBD 344 7. Acknowledgements 346 Many ideas are from the discussion in the DNSOP and DNSEXT mailling 347 list. Thanks a lot to all in the list. Many important comments and 348 suggestions are contributed by many members of the DNSEXT and DNSOP 349 WGs. 351 8. Change History 353 [[anchor25: RFC Editor: Please remove this section.]] 355 8.1. draft-yao-dnsext-msig: Version 00 357 o MSIG for lightweight DNSSEC 359 9. Normative References 361 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 362 STD 13, RFC 1034, November 1987. 364 [RFC1035] Mockapetris, P., "Domain names - implementation and 365 specification", STD 13, RFC 1035, November 1987. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 371 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 372 RFC 2136, April 1997. 374 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 375 RFC 2671, August 1999. 377 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 378 RFC 2672, August 1999. 380 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 381 (RR) Types", RFC 3597, September 2003. 383 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 384 Engineering Team (JET) Guidelines for Internationalized 385 Domain Names (IDN) Registration and Administration for 386 Chinese, Japanese, and Korean", RFC 3743, April 2004. 388 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 389 Rose, "DNS Security Introduction and Requirements", 390 RFC 4033, March 2005. 392 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 393 Rose, "Resource Records for the DNS Security Extensions", 394 RFC 4034, March 2005. 396 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 397 Rose, "Protocol Modifications for the DNS Security 398 Extensions", RFC 4035, March 2005. 400 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 401 Security (DNSSEC) Hashed Authenticated Denial of 402 Existence", RFC 5155, March 2008. 404 Author's Address 406 Jiankang YAO 407 CNNIC 408 No.4 South 4th Street, Zhongguancun 409 Beijing 411 Phone: +86 10 58813007 412 Email: yaojk@cnnic.cn