idnits 2.17.1 draft-timms-encrypt-naptr-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 652. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 665. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 12, 2008) is 5765 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3761 (Obsoleted by RFC 6116, RFC 6117) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ENUM B. Timms 3 Internet-Draft J. Reid 4 Intended status: Experimental Telnic 5 Expires: January 13, 2009 J. Schlyter 6 Kirei AB 7 July 12, 2008 9 IANA Registration for Encrypted ENUM 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 13, 2009. 37 Abstract 39 This document requests IANA registration of the "X-Crypto" 40 Enumservice. This Enumservice indicates that its NAPTR holds a 41 Uniform Resource Identifier that carries encrypted content from the 42 fields of another (unpublished) Protected NAPTR, for use in E.164 43 Number Mapping (ENUM). 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. The problem . . . . . . . . . . . . . . . . . . . . . . . 3 49 1.1.1. The requirements . . . . . . . . . . . . . . . . . . . 3 50 1.2. The solution . . . . . . . . . . . . . . . . . . . . . . . 4 51 1.2.1. Protected fields . . . . . . . . . . . . . . . . . . . 4 52 1.2.2. Protection process . . . . . . . . . . . . . . . . . . 5 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 3. Enumservice Registration - X-Crypto . . . . . . . . . . . . . 7 55 4. Functional Specification . . . . . . . . . . . . . . . . . . . 8 56 4.1. Order . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.2. Preference . . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.3. Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 4.4. Regexp . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 4.5. Replacement . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.6. Encrypted Payload Generation . . . . . . . . . . . . . . . 9 62 5. Ciphersuite Subtypes . . . . . . . . . . . . . . . . . . . . . 10 63 5.1. Crypto Algorithms . . . . . . . . . . . . . . . . . . . . 10 64 5.2. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5.3. Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 6.1. Terminal NAPTR Example . . . . . . . . . . . . . . . . . . 13 68 6.2. Non-Terminal NAPTR Example . . . . . . . . . . . . . . . . 14 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 76 Intellectual Property and Copyright Statements . . . . . . . . . . 21 78 1. Introduction 80 1.1. The problem 82 The Domain Name System or DNS ([RFC1034],[RFC1035]) is a global 83 system; it does not differentiate on the data it returns. If a 84 Naming Authority Pointer (NAPTR) resource record [RFC3403] is 85 published in DNS, then by definition the same Resource Record Set 86 (RRset) will be returned in response to a query, regardless of the 87 user placing that query. 89 Where Universal Resource Indicators (URIs, defined in [RFC3986]) are 90 published within DNS (inside NAPTRs), the registrant may prefer to 91 make these available only to groups of individuals that he or she has 92 selected. Given the global nature of DNS, this can be a problem. 94 It is not reliably possible to return different RRset content to 95 different queries, depending on the user making the request. Even if 96 the authoritative server has been configured to discriminate based on 97 the source of the query, if there are any intermediary recursive 98 resolvers, the query may not even be passed to the authoritative 99 server and the response returned to the querying DNS client may not 100 be as the authoritative server would have chosen. It can also be 101 challenging to configure and maintain the authoritative server, and 102 this may also involve special configuration of each client that will 103 query for and use the data. 105 1.1.1. The requirements 107 There should be no need to use any special configuration for the 108 authoritative name servers, clients, or any intermediary recursive 109 resolvers when using this scheme. Also, there should be no special 110 DNS processing for the resource records used in any DNS components. 111 As a secondary requirement that follows from these, the same content 112 should be published in DNS and so made available to all without 113 discrimination. This will match the distributed design of the DNS 114 and maintain the effectiveness of the cacheing architecture. 116 However, the value of chosen content should be protected in such a 117 way that it is understandable only by a selected set of users. 119 There should be no performance impact on those clients that choose 120 not to process protected data. Thus it is important that the 121 recipient of this data can detect immediately that it is protected, 122 and either process it to extract the protected content using its 123 private knowledge, or immediately discard the data if it is not 124 interested in such protected records. 126 1.2. The solution 128 A general solution for all DNS resource records that meets these 129 requirements is very difficult; the performance requirements for DNS 130 in general are severe. NAPTRs stored in ENUM [RFC3761] domains may 131 contain personally identifying information, so finding a solution may 132 be considered more pressing for such NAPTRs, and some restrictions or 133 processing costs may therefore be acceptable. Also, in the case of 134 NAPTRs a solution may be possible, as the problem is more restricted. 135 NAPTRs hold a small number of well defined fields. Not all of these 136 fields in a NAPTR will be sensitive and so require protection. 138 Those fields to be protected can be encrypted using a key known to 139 the intended users. Thus a "Protected" NAPTR can be processed into 140 two parts; the protected fields carried in a ciphertext, and the 141 public fields. A "Container" NAPTR can itself be used to carry this 142 ciphertext (inside its Regexp field content, in a URI), along with 143 those fields that are considered public and are not protected. These 144 public fields can be copied from the Protected NAPTR into this 145 Container NAPTR. 147 The Container NAPTR can be stored and retrieved in the normal way. 148 It will have an Enumservice indicating that it acts as a container 149 and MUST be decoded before the original Protected NAPTR can be 150 reconstructed and processed. When an ENUM client retrieves such a 151 Container NAPTR, it can immediately know that this requires 152 cryptographic processing, and if that client is not interested in 153 such processing, the NAPTR can be discarded. 155 1.2.1. Protected fields 157 There is no great benefit to encrypting all of the RDATA (Resource 158 record Data) for a NAPTR. The ORDER and PREFERENCE/PRIORITY fields 159 are used to indicate the preferred order in which the records within 160 a returned NAPTR RRset will be processed. Whether a particular NAPTR 161 acts as a container for a Protected NAPTR's content or not, the order 162 in which it will be processed should remain the same; there is no 163 change to the Dynamic Delegation Discovery System (DDDS) algorithm 164 specified in [RFC3402]. 166 If instead the Container NAPTR had a different ORDER and PREFERENCE/ 167 PRIORITY field values from those held in the Protected NAPTR, it 168 might be possible for a Container NAPTR to be considered first (as it 169 had a low numerical order/preference value), but, once decoded, the 170 Protected NAPTR content it contained was of a much lower priority, 171 and so should not be processed at that point. This would be 172 inappropriate, and so the ORDER and PREFERENCE/PRIORITY fields will 173 remain the same in both Protected and Container NAPTRs. 175 Thus the ORDER and PREFERENCE/PRIORITY field values should be 176 considered public and be copied from the Protected NAPTR into the 177 Container NAPTR. However, all the other fields (flags, services, 178 regexp, and replacement) are sensitive in nature, and so that portion 179 of the binary format of the RDATA in which they are held will form 180 the plaintext that will be protected before publication in DNS. 182 1.2.2. Protection process 184 The NAPTR to be protected can have these sensitive fields placed into 185 a plaintext buffer. The buffer content is then encrypted using an 186 appropriate key to create a ciphertext. The ciphertext can then be 187 "armoured" into a form that can be presented in a data URI [RFC2397]. 188 That URI can then be placed in a Container NAPTR within its Regexp 189 field, along with the "public" ORDER and PREFERENCE/PRIORITY fields 190 copied from the Protected NAPTR, together with a dedicated 191 Enumservice, terminal URI flag field ('u') and an empty Replacement 192 field. 194 If this Container NAPTR has an appropriate Enumservice then its 195 nature will be immediately detectable by the recipient of that NAPTR. 196 If the recipient has the appropriate key to decode the URI data, then 197 it can decrypt the URI content to form a buffer with the plaintext 198 fields. These fields (in combination with the ORDER and PREFERENCE/ 199 PRIORITY fields that have been copied into the Container NAPTR and 200 have not been encoded) can be reconstructed into the RDATA that would 201 have existed in the original Protected NAPTR. That Protected NAPTR 202 content can then be processed by the client in the normal way. 204 2. Terminology 206 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 207 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 208 document are to be interpreted as described in [RFC2119]. 210 3. Enumservice Registration - X-Crypto 212 The following template contains information required for the IANA 213 registrations of the 'X-Crypto' Enumservice, according to Section 3 214 of RFC 3761: 216 Enumservice Name: "X-Crypto" 218 Enumservice Type: "x-crypto" 220 Enumservice Subtype: "data" 222 Enumservice Sub-subtype: see Section 5 224 URI Schemes: "data" 226 Functional Specification: see Section 4 228 Security Specification: see Section 7 230 Intended Usage: COMMON 232 Author(s): Ben Timms, Jim Reid, Jakob Schlyter. (for authors contact 233 details see Authors' Addresses section). 235 Any other information that the author deems interesting: None 237 4. Functional Specification 239 The basic concept is covered in Section 1.2 and the process is 240 covered in Section 1.2.2. This section describes in detail how each 241 of the fields are handled. 243 Publication and use of a NAPTR with this Enumservice is based on two 244 concepts: 246 A Protected NAPTR that contains sensitive field values, and is not 247 stored and published in DNS. 249 A Container NAPTR with this Enumservice that holds the protected 250 fields in encrypted form within its Regexp field. This NAPTR 251 carries the "x-crypto" Enumservice 253 The Container NAPTR resource record fields are as follows: 255 4.1. Order 257 The value of the order field is copied in clear from the RDATA of the 258 Protected NAPTR into the Container NAPTR. It is not encoded. 260 4.2. Preference 262 The value of the preference field is copied in clear from the RDATA 263 of the Protected NAPTR to the Container NAPTR. It is not encoded. 265 4.3. Services 267 The value of the services field for the Container NAPTR is set to 268 "E2U+x-crypto:data:" combined with the ciphersuite sub-subtype 269 (Section 5). 271 4.4. Regexp 273 The encrypted payload (Section 4.6) is encoded in Base64 [RFC4648], 274 and transported as the value of a data URI [RFC2397] inside the 275 Container NAPTR. 277 Container NAPTR Regexp Example: 278 !^.*$!data:;base64,bWVrbWl0YXNkaWdvYXQK! 280 4.5. Replacement 282 The value of the Container NAPTR's replacement field MUST be set to 283 ".". 285 4.6. Encrypted Payload Generation 287 The Encrypted Payload consists of a base64 "armoured" string holding 288 an encrypted, optionally padded ciphertext reflecting a portion of 289 the Protected NAPTR's RDATA. 291 The portion of the Protected NAPTR RDATA holding its Flags, Services, 292 Regexp and Replacement fields is treated as the plaintext to be 293 processed. This plaintext is (optionally) padded and the resulting 294 block is then encrypted, to form the ciphertext. Potentially, an 295 optional hash may be generated from this. Once this cipehertext has 296 been generated, it is further encoded in Base64 to form the encrypted 297 payload that is then used as the value of the Container NAPTR's URI. 299 5. Ciphersuite Subtypes 301 The enumservice sub-subtype carries the ciphersuite used for the 302 encrypted payload. 304 Ciphersuite sub-subtype example: RSA 1024-bit with PKCS#1.5 padding 305 and no hash would be encoded as 0x8210 and presented as enumservice 306 "E2U+x-crypto:data:8210". 308 5.1. Crypto Algorithms 310 A 1-byte field indicating the encryption algorithm is used for the 311 encrypted payload (Section 4.6). 313 +-------+----------------------+ 314 | Value | Encryption Algorithm | 315 +-------+----------------------+ 316 | 0x00 | NULL | 317 | | | 318 | 0x81 | RSA-512 | 319 | | | 320 | 0x82 | RSA-1024 | 321 | | | 322 | 0x83 | RSA-1536 | 323 | | | 324 | 0x84 | RSA-2048 | 325 | | | 326 | 0x85 | RSA-3072 | 327 | | | 328 | 0x86 | RSA-4096 | 329 +-------+----------------------+ 331 5.2. Padding 333 A 4-bit field indicating what padding algorithm is used for the 334 encrypted payload (Section 4.6). 336 +-------+-------------------+ 337 | Value | Padding Algorithm | 338 +-------+-------------------+ 339 | 0x0 | NULL | 340 | | | 341 | 0x1 | PKCS #1.5 | 342 | | | 343 | 0x2 | OAEP | 344 +-------+-------------------+ 346 5.3. Hash 348 A 4-bit field indicating what hash algorithm is used for the 349 encrypted payload (Section 4.6). 351 +-------+----------------+ 352 | Value | Hash Algorithm | 353 +-------+----------------+ 354 | 0x0 | NULL | 355 | | | 356 | 0x1 | MD2 | 357 | | | 358 | 0x2 | MD5 | 359 | | | 360 | 0x3 | SHA-1 | 361 | | | 362 | 0x4 | SHA-224 | 363 | | | 364 | 0x5 | SHA-256 | 365 | | | 366 | 0x6 | SHA-384 | 367 | | | 368 | 0x7 | SHA-512 | 369 +-------+----------------+ 371 6. Examples 373 In these examples, a 1024-bit RSA key pair is used for encryption and 374 decryption. The plaintext has cryptographic padding applied prior to 375 encryption, using the PKCS 1.5 algorithm. There is a null hash 376 applied to this. The ciphersuite value (i.e. the Enumservice sub- 377 sub-type string held in the container NAPTR) will be '8210'. The 378 resultant ciphertext is further "armoured" using Base 64 encoding, 379 and is placed into a data URI in that container NAPTR. A "default" 380 or "greedy" Extended Regular Expression, or ERE (i.e. '!^.*$!') is 381 used in the container NAPTR Regexp field. Note that (in keeping with 382 [RFC4648], section 3.1), the "aromouring" process MUST NOT add line 383 feeds to the base-encoded data. 385 For ease of presentation the examples are shown in textual form, but 386 the encryption process works on the binary form of the RDATA fields. 388 Note that, using this encryption, encoding and ERE mechanism, the 389 limit to the length of the "plaintext" (i.e. the fields of the RDATA 390 to be protected) is 117 bytes. This is because RSA is a block 391 cipher, with in this case 1024 bits (128 bytes) as the block size, 392 and the PKCS #1.5 padding to be added to the plaintext consumes 11 393 bytes, leaving a maximum plaintext size of 117 bytes. 395 Once encrypted, the ciphertext is also 128 bytes, but this is in 396 binary form, and has to be further "armoured" for carriage inside the 397 data: URI. The Base 64 encoding process expands the ciphertext to 398 4/3 (rounded up to the nearest 4 bytes) of its size in binary form, 399 giving a text block of 172 bytes. To this has to be added the rest 400 of the container NAPTR's Regexp content, giving a Regexp field length 401 of 193 bytes. Note that this field length is constant, as the 402 ciphertext is always the same length when using the same encryption 403 and padding scheme (regardless of the length of the plaintext fields 404 to be protected and whether these fields reflect a terminal or non- 405 terminal NAPTR). 407 In the following examples, it is assumed that the private key (in 408 PKCS 8 format, protected with the pass phrase "pkcs8passphrase", and 409 expressed in PEM format), is: 411 -----BEGIN ENCRYPTED PRIVATE KEY----- 412 MIICoTAbBgkqhkiG9w0BBQMwDgQIpwb76GrK0AgCAggABIICgEsRtkQ2isuKq3Cl 413 8wpAfDxzzFbumj0HdGu7WLEElVYaLt4CvRlz5kL3SK2G8ydpsdU104s0RnzgPGFv 414 63zsJZ5bC6d4lCcWMjbhv+U91YUhlrc6R6UHhIN4BSBWTeA/Ia/U7bwZm/TV7ke1 415 eeLOdsyzEnPr9lj3v1wdHFYU6CMY1lRP/lbqexVQMYEev5/w+tu9LyGdP3MPnnUC 416 N/OVk67OkwBqrBnQpHtHLC7i0bq6srLaJWB7nFVa/iXlQ8lCwFRGwV7RDq6JvgI2 417 LjgJArLG8i7QBx+WE/+LwLAessmU4RUzzvQhnlWdf3UkXR/hRDPRhJFFrr5zjfUr 418 cF5CfZms4WhMh+epqnlaoaX7uEj1gQ9gLvNef3b68akpRVIFuLBnqcdbahr0rzQA 419 /LT5e62jfo2saSG9vVAY7f1fOmrh9K9+S69rlbQ4JLzx+sttPTty9CscIZf3/cDM 420 1GNdumwG1HewzkVuzvIlyJfLbM1ftWhv0tWTe8pPFqccTFYvwpjVnOxN6yr8EMUy 421 8VTyDCZT/us8E6vtei2fbvLHnmRzIqCgHUAYBVKM+cwrGELCuSBbx6pmOp21EyGH 422 5+Lobg0XYjArVxgynNvAU/mmQWbdVqhkfrIGhywCvi1+Jpigvn+2zBayCfPitdxh 423 BjvYhEp6qSE0/QWog4Qn6t5TaDK7ddV39Tw2pyuE1Gh+tAfZWrwO0aF9NKI9G5mJ 424 Db3Jqm9UzAoulH8cnMdCAa7oDVCl/8ky1VKTIz8fe3bVsMCm8Cgv3/vz8vupaGV5 425 exzJUEeEJweenReOaI8Eocl2qSKmcrtlhAQI+l77KnvM3J0QSPSxeH203OnLovG3 426 lQkJjd4= 427 -----END ENCRYPTED PRIVATE KEY----- 429 The public key, expressed in PEM format, is: 431 -----BEGIN PUBLIC KEY----- 432 MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDoOyVQpfJlai3i7RlF5iGGlYUb 433 /HXOuyV1IVKoQ1iQQvm91gU5L10GwVWN1WY4yfqYtPXnJMoMbAIK72wNnaB6Jo4/ 434 ELbi40yOQSIe4TKXVcfMkFbpJlN7FfktHtpLai60zsT8Ywt4OF8rUFmb5CdE3gtV 435 yqQfmfczYheXqPW7iwIDAQAB 436 -----END PUBLIC KEY----- 438 6.1. Terminal NAPTR Example 440 This example shows a NAPTR holding a SIP Enumservice as the protected 441 NAPTR. Given that a terminal E2U (ENUM) NAPTR is to be protected, 442 the combined maximum length of the Enumservice string, the ERE 443 pattern and the original URI is (117 - 12) bytes, or 105 bytes. If a 444 "greedy" ERE field is used in that protected NAPTR, the space 445 available for the Enumservice string and the URI is 105 - 4 bytes, or 446 101 bytes. In the example shown here, the NAPTR to be protected has 447 a SIP Enumservice (and corresponding sip: URI scheme). This means 448 that the SIP address value can be a maximum of 94 bytes long. In 449 this case, it occuplies 24 bytes. 451 The protected NAPTR RDATA: 453 100 50 'u' 'E2U+sip' '!^.*$!sip:alice@wonderland.example!' . 455 Is replaced by the container NAPTR RDATA: 457 100 50 'u' 'E2U+X-crypto:data:8210' 458 '!^.*$!data:;base64,OQZl3x9TEaZtQamA5t3IJqXaKUT6QuV+yLtW34/hszd 459 D2jtSwavlxiax8CDMWekikXkgbPQqEo7X6g8aX3REiXVJ/PqrbxFASIIktnIIVE 460 rZU3RVl8WAvxQvWGs+wEY3YAi4UnOoqAOdbv3tsV0i4h15I+wePz9Rw9VBpU95h 461 Wc=!' . 463 6.2. Non-Terminal NAPTR Example 465 In this example, a non-terminal NAPTR is protected. As the 466 replacement field in a NAPTR is not permitted (as specified in RFC 467 3403) to use DNS domain compression, the fully qualified domain name 468 of the target domain is held in the replacement field. This fully 469 qualified domain name is, of course, stored in binary form within the 470 RDATA. 472 Note that, using the same protection scheme (1024-bit RSA, with PKCS 473 1.5 padding, null hash), the maximum length of the fully qualified 474 domain name will be 117 - 3, or 114 bytes. In this example, the 475 fully qualified domain name is 1+5+1+10+1+7+1 = 26 bytes long. 477 The protected non-terminal NAPTR RDATA: 479 100 51 '' '' '' alice.wonderland.example. 481 Is replaced by the container NAPTR RDATA: 483 100 51 'u' 'e2u+x-crypto:data:8210' 484 '!^.*$!data:;base64,j+WNPPwriy5pu4SfabMavRtE+c/f3Sk62Ab5TNYOomo 485 RcGrKk5q23i6BB4fp71+z3ezK1U91jTdpzmpF0M7WVs9M9AnhDxyrbQwo1mP/uU 486 YpflaZuG5aEnY14aTntAldh7UacPvfaiWc1QPg/6C9Wb7MBedmZAYajc2YZHgKQ 487 1o=!' . 489 7. Security Considerations 491 This is an Enumservice for a NAPTR intended to carry protected NAPTR 492 content in encrypted form. It does not discuss the means by which 493 the keys needed to decrypt the protected content are exchanged. For 494 this Enumservice registration, this is considered "out of scope". 495 However, the technique used for key exchange is important, and must 496 be considered thoroughly; there is little point in applying a complex 497 encryption scheme if the keys are available to eavesdroppers. Of 498 course, although technically permitted, confidentiality will not be 499 achieved unless a non-null encryption is applied. 501 There are limitations on field size within DNS, so that, for example, 502 the Regexp field has a maximum length of 255 bytes. Several of these 503 bytes will be taken up in the container NAPTR's Regexp field with the 504 sub-field delimiters, with the ERE sub-field content, and with the 505 URI scheme itself. There is limited space to carry the armoured 506 ciphertext as the data URI value, given the armouring choice proposed 507 here and the simple use of the existing Regexp field to carry the 508 protected data. This will in turn limit the choices for encryption 509 method, hash algorithm, and any padding. See also the examples 510 above. 512 Even if an eavesdropper cannot decode the content carried in a 513 container NAPTR, the fact that ORDER and PREFERENCE/PRIORITY fields 514 are copied from the protected NAPTR opens the possibility of opaque 515 traffic analysis. If the ORDER and PREFERENCE/PRIORITY field values 516 for a NAPTR within a RRSet change (for example, to reflect the domain 517 owner going from office to home) then this change will be reflected 518 in the NAPTR even if it is protected. Simply due to changes in RRSet 519 relative ORDER and PREFERENCE/PRIORITY values, an attacker might 520 surmise that the protected data was associated with the domain 521 owner's office or home number. This information might in itself be 522 useful to the attacker (for example, by indicating when the domain 523 owner was or was not present at a particular location). 525 Finally, if the value of a contact (such as a SIP URI or telephone 526 number) were to be available to an attacker using other means, then 527 there may be potential for differential cryptographic analysis based 528 on an assumed "known plaintext". The amount of data available to an 529 attacker with realistic numbers of NAPTRs is small, but it is 530 important to use appropriate cryptographic padding to limit the 531 potential for such an attack. 533 These issues mean that the environment in which NAPTRs with this 534 Enumservice can be used may be restricted, and further security 535 analysis will depend on deployment experience. 537 An analysis of threats specific to the dependence of ENUM on the DNS, 538 and the applicability of DNSSEC ("Domain Name Security") [RFC4035] to 539 these, is provided in [RFC3833]. 541 8. IANA Considerations 543 This document requests registration of the "X-Crypto" Enumservice 544 with the "x-crypto:data:" type according to the 545 guidelines and specifications in RFC 3761 [RFC3761] and the 546 definitions in this document. This Enumservice is intended for use 547 with the "data:" URI scheme. 549 9. Acknowledgements 551 The authors gratefully acknowledge the contributions of Romek 552 Szczesniak. He helped greatly to clarify some of the issues with 553 deployed security schemes and current implementations. We also 554 acknowledge the support of Khashayar Mahdavi whose original idea this 555 draft embodies, and Henri Asseily for driving the development of the 556 environment in which this is being used. 558 10. References 560 10.1. Normative References 562 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 563 Requirement Levels", BCP 14, RFC 2119, March 1997. 565 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 566 August 1998. 568 [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 569 Part Two: The Algorithm", RFC 3402, October 2002. 571 [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) 572 Part Three: The Domain Name System (DNS) Database", 573 RFC 3403, October 2002. 575 [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform 576 Resource Identifiers (URI) Dynamic Delegation Discovery 577 System (DDDS) Application (ENUM)", RFC 3761, April 2004. 579 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 580 Encodings", RFC 4648, October 2006. 582 10.2. Informative References 584 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 585 STD 13, RFC 1034, November 1987. 587 [RFC1035] Mockapetris, P., "Domain names - implementation and 588 specification", STD 13, RFC 1035, November 1987. 590 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 591 Name System (DNS)", RFC 3833, August 2004. 593 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 594 Resource Identifier (URI): Generic Syntax", STD 66, 595 RFC 3986, January 2005. 597 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 598 Rose, "Protocol Modifications for the DNS Security 599 Extensions", RFC 4035, March 2005. 601 Authors' Addresses 603 Ben Timms 604 Telnic 605 37 Percy Street 606 London W1T 2DJ 607 United Kingdom 609 Email: btimms@telnic.org 611 Jim Reid 612 Telnic 613 37 Percy Street 614 London W1T 2DJ 615 United Kingdom 617 Email: jim@telnic.org 619 Jakob Schlyter 620 Kirei AB 621 P.O. Box 53204 622 Goteborg SE-400 16 623 Sweden 625 Email: jakob@kirei.se 627 Full Copyright Statement 629 Copyright (C) The IETF Trust (2008). 631 This document is subject to the rights, licenses and restrictions 632 contained in BCP 78, and except as set forth therein, the authors 633 retain all their rights. 635 This document and the information contained herein are provided on an 636 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 637 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 638 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 639 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 640 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 641 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 643 Intellectual Property 645 The IETF takes no position regarding the validity or scope of any 646 Intellectual Property Rights or other rights that might be claimed to 647 pertain to the implementation or use of the technology described in 648 this document or the extent to which any license under such rights 649 might or might not be available; nor does it represent that it has 650 made any independent effort to identify any such rights. Information 651 on the procedures with respect to rights in RFC documents can be 652 found in BCP 78 and BCP 79. 654 Copies of IPR disclosures made to the IETF Secretariat and any 655 assurances of licenses to be made available, or the result of an 656 attempt made to obtain a general license or permission for the use of 657 such proprietary rights by implementers or users of this 658 specification can be obtained from the IETF on-line IPR repository at 659 http://www.ietf.org/ipr. 661 The IETF invites any interested party to bring to its attention any 662 copyrights, patents or patent applications, or other proprietary 663 rights that may cover technology that may be required to implement 664 this standard. Please address the information to the IETF at 665 ietf-ipr@ietf.org.