idnits 2.17.1 draft-krecicki-dprive-dnsenc-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3106 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) == Missing Reference: 'TBD' is mentioned on line 531, but not defined ** Downref: Normative reference to an Unknown state RFC: RFC 1033 ** Obsolete normative reference: RFC 3152 (Obsoleted by RFC 3596) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force W. Krecicki 3 Internet-Draft Internet Systems Consortium 4 Intended status: Standards Track October 19, 2015 5 Expires: April 21, 2016 7 Stateless DNS Encryption 8 draft-krecicki-dprive-dnsenc-01 10 Abstract 12 The DNS is the last common Internet protocol that has no encryption 13 scheme and therefore provides no privacy to the users. This document 14 proposes an extensible mechanism providing encryption of DNS queries 15 and responses with method for secure retrieval and verification of 16 validity of encryption keys. It is independent of the underlying 17 transport protocol. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 21, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Communication process . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Key retrieval . . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Query creation . . . . . . . . . . . . . . . . . . . . . 4 58 2.2.1. Method 1 . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2.2. Method 2 . . . . . . . . . . . . . . . . . . . . . . 6 60 2.3. Query processing . . . . . . . . . . . . . . . . . . . . 7 61 2.4. Response creation . . . . . . . . . . . . . . . . . . . . 7 62 2.5. Response processing . . . . . . . . . . . . . . . . . . . 8 63 3. Data types . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1. NSK record . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1.1. Wire format . . . . . . . . . . . . . . . . . . . . . 8 66 3.1.2. Presentation format . . . . . . . . . . . . . . . . . 10 67 3.2. DNSENC option . . . . . . . . . . . . . . . . . . . . . . 11 68 4. Encryption schemes . . . . . . . . . . . . . . . . . . . . . 11 69 4.1. Asymmetric schemes . . . . . . . . . . . . . . . . . . . 11 70 4.2. Symmetric schemes . . . . . . . . . . . . . . . . . . . . 12 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 6.1. NSK RR type . . . . . . . . . . . . . . . . . . . . . . . 12 74 6.2. DNSENC EDNS option . . . . . . . . . . . . . . . . . . . 12 75 6.3. ENCRYPT OpCode . . . . . . . . . . . . . . . . . . . . . 12 76 6.4. BADCRYPT RCODE . . . . . . . . . . . . . . . . . . . . . 13 77 6.5. DNSENC encryption schemes registry . . . . . . . . . . . 13 78 7. Normative References . . . . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 81 1. Introduction 83 The Domain Name System protocol is specified in [RFC1034] and 84 [RFC1035]. DNS messages are unencrypted and therefore prone to 85 eavesdropping. Although it's considered only metadata, there is a 86 lot of information that can be leaked, as explained by [RFC7626]. 88 The DNS protocol is very lightweight - the queries are usually less 89 than 100 bytes long and the responses are usually less than 1000 90 bytes (even with DNSSEC). Existing transport encryption schemes such 91 as TLS for TCP or DTLS for UDP give a huge and unnecessary overhead 92 both in the amount of data sent and retrieved and in the number of 93 packets exchanged between client and server. 95 In DNSENC the query is encrypted using asymmetric cryptography with a 96 securely retrieved key and the response is encrypted using symmetric 97 encryption with a one-time key provided with the query. The DNSENC 98 protocol is uses standard DNS features and does not requires any 99 additional external mechanisms such as a PKI/CA system. 101 The DNSENC communication can be split into three phases: 103 o first the client retrieves public key for the server that is 104 stored in DNS and is DNSSEC signed; this key can then be cached, 106 o the client creates the query, adds a random response encryption 107 key and encrypts the query with the server's public key, 109 o the server decrypts the message, prepares the response and 110 encrypts it with the key provided by client. 112 It has to be noted that for a resolver to bootstrap itself, it has to 113 perform a clear text query to retrieve keys for DNSENC encryption. 114 As this query can be for information from the root zone, no sensitive 115 information is leaked. 117 In an usual case DNSENC will add no additional round-trips to 118 communication, besides the query for root zone servers' NSK record. 119 The message size overhead is around 140 bytes for encapsulation 120 (NOTE: that's using method described in Section 2.2.1), the maximum 121 amount of overhead for encryption depends on the method used and 122 varies from 16 bytes for AES to 512 bytes for RSA. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 2. Communication process 132 2.1. Key retrieval 134 To communicate securely with a server, a client first needs to 135 retrieve the server's public key for asymmetric encryption. This key 136 is stored in an NSK RR described in Section 3.1. The NSK RRset might 137 contain multiple records. The key retrieval process is different for 138 authoritative servers and for recursive servers. 140 For authoritative servers a NSK RRset SHOULD be present at a 141 delegation point in the parent zone. If a NSK RRset is present at 142 the delegation point, the name server MUST return both the NSK RRset 143 and its associated RRSIG RR(s) in the Authority section along with 144 the NS RRset. This reduces the number of round-trips and allows all 145 communication with the child zone's servers to be encrypted. 147 All NSK RRsets MUST be signed with DNSSEC, and NSK RRsets MUST NOT 148 appear at a zone's apex. 150 example.com. 86400 IN NS a.iana-servers.net. 151 example.com. 86400 IN NS b.iana-servers.net. 152 example.com. 86400 IN NSK (...) 153 example.com. 86400 IN NSK (...) 154 example.com. 86400 IN RRSIG NSK (...) 156 For recursive servers and in cases where it is not possible to put 157 the NSK RRset for an authoritative server at a delegation point, the 158 NSK RRset SHOULD be present in the reverse DNS record of servers' IP 159 address, as described in [RFC3152], [RFC1033] and [RFC2317]. The 160 client MUST retrieve this RRset from the server it wants to query. 161 This RRset MUST be DNSSEC signed. For authoritative servers this 162 method is only a fallback and client MUST try to retrieve the key at 163 a delegation point first. 165 5.2.0.192.in-addr.arpa. 86400 IN NSK (...) 167 If the record is not signed the client MUST NOT use the key provided. 168 (TODO enforce encryption, protection against downgrade attack). 170 As there might be multiple NSK RRs in the RRSet it is the client 171 responsibility to choose the highest priority RR that has both query 172 and response schemes supported by the client. 174 2.2. Query creation 176 ----------------------------------------------- 178 NOTE: two alternatives are currently under discussion. Both are 179 fully compatible with the DNS protocol. The first one is kind of a 180 kludge but has better chances to be compatible with not-fully- 181 protocol-compliant forwarders (although it still requires support for 182 EDNS). The second solution is cleaner but might not work with some 183 forwarders as the packet is not a regular DNS QUERY. The author 184 prefers the first method. 186 ----------------------------------------------- 188 After choosing an encryption scheme, the client generates a random 189 response encryption key (symmetrical, eg. AES) and prepares a 190 regular DNS query with an NSK record containing the response 191 encryption scheme and key in the ADDITIONAL section, eg: 193 +-----------------------------------------+ 194 Header | OPCODE=QUERY, ID=997, QR=QUERY | 195 +-----------------------------------------+ 196 Question | QTYPE=A, QCLASS=IN, QNAME=EXAMPLE.COM | 197 +-----------------------------------------+ 198 Answer | | 199 +-----------------------------------------+ 200 Authority | | 201 +-----------------------------------------+ 202 Additional | . NSK IN NSK-RR | 203 +-----------------------------------------+ 205 It has to be noted that this packet is never sent on the wire in raw 206 form, so records in the ADDITIONAL section have no impact on 207 compatibility with non-conforming forwarders. 209 2.2.1. Method 1 211 This message is encrypted using chosen query encryption key and 212 packed, along with encryption key ID, in a DNSENC OPTION, as 213 described in Section 3.2. A new query is created with: 215 o the query id copied from the encrypted message 217 o a .dnsenc.arpa. TXT query in QUERY section, where 218 is a random label that guarantees that should the response be 219 cached by a forwarder, it will not be reused for any other client. 221 o empty ANSWER and AUTHORITY sections 223 o a DNSENC OPTION in ADDITIONAL section 225 eg.: 227 +-----------------------------------------+ 228 Header | OPCODE=QUERY, ID=997, QR=QUERY | 229 +-----------------------------------------+ 230 Question | QTYPE=TXT, QCLASS=IN, | 231 | QNAME=.dnsenc.arpa | 232 +-----------------------------------------+ 233 Answer | | 234 +-----------------------------------------+ 235 Authority | | 236 +-----------------------------------------+ 237 Additional | EDNS0 OPT OPTION-CODE=DNSENC | 238 \ OPTION-DATA=DNSENC-PAYLOAD \ 239 | | 240 +-----------------------------------------+ 242 ...and sent to server. The response encryption key is stored on 243 client along its identifier for decryption. 245 2.2.2. Method 2 247 This message is encrypted using query encryption key and packed 248 inside a query withi the OPCODE set to ENCRYPT: 250 1 1 1 1 1 1 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 252 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 253 | ID | 254 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 255 |QR| ENCRYPT | Z | RCODE | 256 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 257 | ENCRYPTED PAYLOAD LENGTH | 258 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 259 | RESERVED | 260 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 261 | RESERVED | 262 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 263 | RESERVED | 264 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 265 | ENCRYPTION KEY ID | 266 | | 267 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 268 | | 269 / ENCRYPTED PAYLOAD / 270 | | 271 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 273 i...and sent to server. The response encryption key is stored on 274 client along its identifier for decryption. 276 2.3. Query processing 278 When a server supporting DNSENC receives a query for any name in the 279 "dnsenc.arpa." domain it MUST immediately look in ADDITIONAL section 280 for DNSENC OPTION. If the DNSENC OPTION is missing the server MUST 281 respond with a status of REFUSED. The DNSENC OPTION is then decoded. 282 If the server does not have a key with identifier provided in query 283 or the decryption failed the server MUST respond with BADCRYPT 284 response. If the data contained in the decrypted packet is invalid 285 or the query ID is not the same as the encapsulating packet query ID 286 the server MUST respond with FORMERR response. 288 A server that does not support DNSENC should respond with REFUSED 289 response code, although old implementations not supporting [RFC6891] 290 might return FORMERR. 292 A forwarder/proxy MUST pass the message untouched (along with the 293 DNSENC OPTION in the ADDITIONAL section) - as described in [RFC5625]. 294 A forwarder/proxy MUST NOT cache a result for anything within 295 "dnsenc.arpa." domain. 297 2.4. Response creation 299 ----------------------------------------------- 301 NOTE: this section describes creating the response for a query 302 described in Section 2.2.1, the method for creating a response for a 303 query described in Section 2.2.2 is analogous but will be described 304 here iff WG decides to go ahead with this method. 306 ----------------------------------------------- 308 After decryption, the NSK record from the query is saved and the 309 query is processed normally. When the response is ready, a regular 310 DNS response packet is created. This packet is encrypted using 311 previously saved response encryption key sent by client and stored 312 along with the response encryption key ID (to keep the response in 313 the same format as query) in a DNSENC OPTION. A new response packet 314 is created with: 316 o the query ID same as in encrypted packet 318 o the QUESTION section copied from original query 320 o an empty ANSWER and AUTHORITY sections 322 o a DNSENC Option in EDNS(0) OPT RR in the ADDITIONAL section 323 containing the encrypted respose to the "real" query. 325 eg. 327 +-----------------------------------------+ 328 Header | OPCODE=QUERY, ID=997, QR=RESPONSE | 329 +-----------------------------------------+ 330 Question | QTYPE=TXT, QCLASS=IN, | 331 | QNAME=.dnsenc.arpa | 332 +-----------------------------------------+ 333 Answer | | 334 +-----------------------------------------+ 335 Authority | | 336 +-----------------------------------------+ 337 Additional | EDNS0 OPT OPTION-CODE=DNSENC | 338 \ OPTION-DATA=DNSENC-PAYLOAD \ 339 | | 340 +-----------------------------------------+ 342 This is then sent back to the client. 344 2.5. Response processing 346 TODO 348 3. Data types 350 3.1. NSK record 352 The NSK RR consist of priority field, key identifier, server names 353 for which the key can be used (wildcard '*' is supported, empty value 354 means all servers for the zone), query encryption scheme 355 (asymmetrical, eg. rsaes-oaep-2048), query key data and possible 356 response encryption schemes. If the server provides multiple NSK 357 records, it is the client's responsibility to choose the highest 358 priority NSK that has query and response encryption schemes supported 359 by client. 361 3.1.1. Wire format 363 The NSK RR has following format: 365 1 1 1 1 1 1 366 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 367 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 368 | KEY IDENTIFIER | 369 | | 370 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 371 | PRIORITY | RESERVED | 372 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 373 | | 374 / APPLICABLE NS NAME / 375 | | 376 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 377 | ENCRYPTION SCHEME | 378 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 379 | KEY LENGTH | 380 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 381 | | 382 / KEY DATA / 383 | | 384 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 385 | NUMBER OF RESPONSE ENCRYPTION SCHEMES | 386 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 387 | RESPONSE ENCRYPTION SCHEME 1 | 388 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 389 | RESPONSE ENCRYPTION SCHEME 2 | 390 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 391 + ... + 392 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 393 | RESPONSE ENCRYPTION SCHEME N | 394 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 396 where: 398 KEY IDENTIFIER 32-bit key identifier, unique for server 400 PRIORITY 8-bit key priority as preferred by server 402 APPLICABLE NS NAME a of NSes that use this 403 key. This allows for different NSes for 404 a zone to use different keysets (eg. when 405 the secondary is operated by different 406 entity than primary). This field might 407 contain wildcard symbol '*' at any place 408 (including as a part of a single label - 409 eg. 'ns*.foo*bar.example.com'), which 410 matches zero or more characters and can 411 cross label boundaries ('ns*.example.com' 412 matches 'ns.example.com', 413 'ns1.example.com' and 414 'ns1.foobar.example.com'), single '*' 415 means any. 417 ENCRYPTION SCHEME 16-bit identifier of the encryption 418 scheme, as defined in [TBD IANA REGISTRY] 420 KEY DATA encryption key - raw binary data 422 RESPONSE ENCRYPTION SCHEMES list of 16-bit identifiers of response 423 encryption schemes, as defined in [TBD 424 IANA REGISTRY], in order of server 425 preference from most preferred 427 For NSK records retrieved by a resolver as described in Section 2.1 428 ENCRYPTION SCHEME describes the scheme used by client to encrypt the 429 query, which MUST be an asymmetric one. RESPONSE ENCRYPTION SCHEMES 430 MUST contain at least one scheme, and all encryption schemes MUST be 431 symmetric. 433 For NSK records sent in the ADDITIONAL section of a query and used by 434 the server to encrypt response: 436 o PRIORITY MUST be set to 0 438 o APPLICABLE NS NAME MUST be empty 440 o ENCRYPTION SCHEME MUST be symmetric and be one from the list of 441 RESPONSE ENCRYPTION SCHEMES in a NSK record with key used to 442 encrypt this query. 444 o KEY DATA MUST be a one-time, random key 446 o RESPONSE ENCRYPTION SCHEMES MUST be empty 448 3.1.2. Presentation format 450 All numerical fields are presented in decimal form, query key data is 451 base64 encoded, encryption scheme can be represented as a number or 452 as a name, fields are in the same order as in wire format, eg: 454 example.com. 86400 IN NSK (896417428 ; identifier 455 10 ; priority 456 ns*.example.com ; applicable NS name 457 1 ; query encryption 458 ; scheme 459 "bnJfZnJlZV9wYWdlcyAyMTU2NjgKbnJf 460 YWxsb2NfYmF0Y2ggNDE1OQpucl9pbmFj 461 dGl2ZV9hbm9uIDM1NzczNwpucl9hY3Rp 462 IDQ4OTAwMQpucl9kaXJ0eSAxMTUKbnJf 463 ZCAwCg==" ; query key, b64 encoded 464 32769 aes-256 ; response encryption 465 ; schemes 466 ) 468 3.2. DNSENC option 470 The encrypted packet is transmitted as an EDNS(0) option, with 471 OPTION-CODE set to DNSENC (value of [TBD]). The wire format of 472 OPTION-DATA for this option is: 474 1 1 1 1 1 1 475 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 476 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 477 | KEY IDENTIFIER | 478 | | 479 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 480 | | 481 / ENCRYPTED PAYLOAD / 482 | | 483 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 485 The length of the encrypted payload is determined by the OPTION- 486 LENGTH field 488 4. Encryption schemes 490 This document defines basic encryption schemes to be used for query 491 and response encryption. Those schemes SHOULD be implemented by all 492 servers and clients. 494 4.1. Asymmetric schemes 496 TBD: RSAES-1024-EOAP, ECC as a default? 498 4.2. Symmetric schemes 500 TBD: AES-256 502 5. Security Considerations 504 The security of this protocol is based deeply on DNSSEC [RFC4033]. 505 Protection against downgrade attack requires wide adoption of DNSSEC. 507 6. IANA Considerations 509 NOTE: as for now no actions with IANA has been taken. 511 6.1. NSK RR type 513 This document defines a new DNS Resource Record Type, named "NSK". 514 The IANA has assigned a code point from the "Resource Record (RR) 515 TYPEs" sub-registry of the "Domain Name System (DNS) Parameters" 516 registry for this record. 518 TYPE Value Meaning Reference 519 ----- ------ -------------------------- ----------- 520 NSK TBD Name Server Key [this document] 522 6.2. DNSENC EDNS option 524 This document defines a new EDNS option, named "DNSENC". The IANA 525 has assigned a code point from the "DNS EDNS0 Option Codes (OPT)" 526 sub-registry of the "Domain Name System (DNS) Parameters" registry 527 for this option. NOTE: this is required only for Section 2.2.1. 529 Value Name Status Reference 530 ------- -------- --------- ---------------- 531 [TBD] DNSENC Standard [this document] 533 6.3. ENCRYPT OpCode 535 This document defines a new DNS OPCODE, named "ENCRYPT". The IANA 536 has assigned a code point from the "DNS OpCodes" sub-registry of the 537 "Domain Name System (DNS) Parameters" registry for this opcode. 538 NOTE: this is required only for Section 2.2.2. 540 OpCode Name Reference 541 ----- --------------------- -------------------------- 542 TBD ENCRYPT [this document] 544 6.4. BADCRYPT RCODE 546 This document defines a new DNS RCODE, named "BADCRYPT". The IANA 547 has assigned a code point from the "DNS RCODEs" sub-registry of the 548 "Domain Name System (DNS) Parameters" registry for this opcode. 550 OpCode Name Description Reference 551 ----- ------------ ------------------------- ------------------- 552 TBD BADCRYPT Encryption error [this document] 554 6.5. DNSENC encryption schemes registry 556 The IANA has created and maintains a sub-registry (the "DNSENC 557 encryption schemes" registry) of the "Domain Name System (DNS) 558 Parameters" registry. The initial values for this registry are 559 below. 561 An "Expert Review" [RFC5226] is required for the assignment of new 562 scheme value (TBD: Expert or IETF? We should have a proper 563 definition of an encryption scheme). 565 This registry holds a set of 16-bit values identifying an encryption 566 scheme. First bit of first octet is set to 0 for asymmetric 567 encryption schemes, 1 for symmetric encryption schemes. First nibble 568 of second octet is set to 0xf for experimental or vendor-specific 569 schemes. 571 The initial assignments in this registry are: 573 Octet 1 Octet 2 Algorithm Reference 574 ------- ------- ------------------------ --------------- 575 0x00 0x00 Reserved [this document] 576 0x00 0x01 RSAES-2048-OAEP [this document] 577 0x00 0x02 RSAES-4096-OAEP [this document] 578 0x80 0x00 Reserved [this document] 579 0x80 0x01 AES-256 [this document] 580 0x80 0x01 AES-512 [this document] 581 .... 0xf. experimental 582 or vendor-specific 584 7. Normative References 586 [RFC1033] Lottor, M., "Domain Administrators Operations Guide", RFC 587 1033, DOI 10.17487/RFC1033, November 1987, 588 . 590 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 591 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 592 . 594 [RFC1035] Mockapetris, P., "Domain names - implementation and 595 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 596 November 1987, . 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 600 RFC2119, March 1997, 601 . 603 [RFC2317] Eidnes, H., de Groot, G., and P. Vixie, "Classless IN- 604 ADDR.ARPA delegation", BCP 20, RFC 2317, DOI 10.17487/ 605 RFC2317, March 1998, 606 . 608 [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, DOI 609 10.17487/RFC3152, August 2001, 610 . 612 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 613 Rose, "DNS Security Introduction and Requirements", RFC 614 4033, DOI 10.17487/RFC4033, March 2005, 615 . 617 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 618 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 619 DOI 10.17487/RFC5226, May 2008, 620 . 622 [RFC5625] Bellis, R., "DNS Proxy Implementation Guidelines", BCP 623 152, RFC 5625, DOI 10.17487/RFC5625, August 2009, 624 . 626 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 627 for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/ 628 RFC6891, April 2013, 629 . 631 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 632 DOI 10.17487/RFC7626, August 2015, 633 . 635 Author's Address 637 Witold Krecicki 638 Internet Systems Consortium 639 950 Charter Street 640 Redwood City, CA 94063 641 USA 643 Email: wpk@isc.org 644 URI: http://www.isc.org