idnits 2.17.1 draft-strad-trans-redaction-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances 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 (January 17, 2017) is 2654 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 179 -- Looks like a reference, but probably isn't: '2' on line 181 -- Looks like a reference, but probably isn't: '1' on line 184 -- Looks like a reference, but probably isn't: '7' on line 189 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-24 ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRANS (Public Notary Transparency) R. Stradling 3 Internet-Draft Comodo CA, Ltd. 4 Intended status: Experimental E. Messeri 5 Expires: July 21, 2017 Google UK Ltd. 6 January 17, 2017 8 Certificate Transparency: Domain Label Redaction 9 draft-strad-trans-redaction-01 11 Abstract 13 This document defines mechanisms to allow DNS domain name labels that 14 are considered to be private to not appear in public Certificate 15 Transparency (CT) logs, while still retaining most of the security 16 benefits that accrue from using Certificate Transparency. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 21, 2017. 35 Copyright Notice 37 Copyright (c) 2017 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 54 3. Redaction Mechanisms . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Using Wildcard Certificates . . . . . . . . . . . . . . . 3 56 3.2. Using a Name-Constrained Intermediate CA . . . . . . . . 4 57 3.2.1. Presenting SCTs, Inclusion Proofs and STHs . . . . . 5 58 3.2.2. Matching an SCT to the Correct Certificate . . . . . 6 59 3.3. Redacting Labels in Precertificates . . . . . . . . . . . 6 60 3.3.1. redactedSubjectAltName Certificate Extension . . . . 7 61 3.3.2. Verifying the redactedSubjectAltName extension . . . 8 62 3.3.3. Reconstructing the TBSCertificate . . . . . . . . . . 8 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 4.1. Avoiding Overly Redacted Domain Names . . . . . . . . . . 8 65 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 66 5.1. Ensuring Effective Redaction . . . . . . . . . . . . . . 9 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 70 7.2. Informative References . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 Some domain owners regard certain DNS domain name labels within their 76 registered domain space as private and security sensitive. Even 77 though these domains are often only accessible within the domain 78 owner's private network, it's common for them to be secured using 79 publicly trusted Transport Layer Security (TLS) server certificates. 81 Certificate Transparency v1 [RFC6962] and v2 82 [I-D.ietf-trans-rfc6962-bis] describe protocols for publicly logging 83 the existence of TLS server certificates as they are issued or 84 observed. Since each TLS server certificate lists the domain names 85 that it is intended to secure, private domain name labels within 86 registered domain space could end up appearing in CT logs, especially 87 as TLS clients develop policies that mandate CT compliance. This 88 seems like an unfortunate and potentially unnecessary privacy leak, 89 because it's the registered domain names in each certificate that are 90 of primary interest when using CT to look for suspect certificates. 92 TODO: Highlight better the differences between registered domains and 93 subdomains, referencing the relevant DNS RFCs. 95 2. Requirements Language 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in [RFC2119]. 101 3. Redaction Mechanisms 103 We propose three mechanisms, in increasing order of implementation 104 complexity, to allow certain DNS domain name labels to not appear in 105 public CT logs: 107 o Using wildcard certificates (Section 3.1) is the simplest option, 108 but it only covers certain use cases. 110 o Logging a name-constrained intermediate CA certificate in place of 111 the end-entity certificate (Section 3.2) covers more, but not all, 112 use cases. 114 o Therefore, we define a domain label redaction mechanism 115 (Section 3.3) that covers all use cases, at the cost of 116 considerably increased implementation complexity. 118 We anticipate that TLS clients may develop policies that impose 119 additional compliancy requirements on the use of the Section 3.2 and 120 Section 3.3 mechanisms. 122 To ensure effective redaction, CAs and domain owners should note the 123 privacy considerations (Section 5). 125 TODO(eranm): Do we need to further expand (either here or in the 126 following subsections) on when each of the mechanisms is/isn't 127 suitable? 129 TODO: Previously, these mechanisms were defined in earlier revisions 130 of CTv2 [I-D.ietf-trans-rfc6962-bis], and nothing was said about 131 compatibility with CTv1. But now, given that these mechanisms have 132 been decoupled from [I-D.ietf-trans-rfc6962-bis], and given that at 133 least one major TLS client has announced a policy of mandatory CT 134 compliance that will almost certainly take effect before CTv2 is 135 widely deployed, we should consider making some or all of these 136 mechnanisms compatible with both CTv1 and CTv2. 138 3.1. Using Wildcard Certificates 140 A certificate containing a DNS-ID [RFC6125] of "*.example.com" could 141 be used to secure the domain "topsecret.example.com", without 142 revealing the label "topsecret" publicly. 144 Since TLS clients only match the wildcard character to the complete 145 leftmost label of the DNS domain name (see Section 6.4.3 of 146 [RFC6125]), a different mechanism is needed when any label other than 147 the leftmost label in a DNS-ID is considered private (e.g., 148 "top.secret.example.com"). Also, wildcard certificates are 149 prohibited in some cases, such as Extended Validation Certificates 150 [EV.Certificate.Guidelines]. 152 3.2. Using a Name-Constrained Intermediate CA 154 An intermediate CA certificate or intermediate CA precertificate that 155 contains the Name Constraints [RFC5280] extension MAY be logged in 156 place of end-entity certificates issued by that intermediate CA, as 157 long as all of the following conditions are met: 159 o there MUST be a non-critical extension (OID 1.3.101.76, whose 160 extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)). 161 This extension is an explicit indication that it is acceptable to 162 not log certificates issued by this intermediate CA. 164 o there MUST be a Name Constraints extension, in which: 166 * permittedSubtrees MUST specify one or more dNSNames. 168 * excludedSubtrees MUST specify the entire IPv4 and IPv6 address 169 ranges. 171 Below is an example Name Constraints extension that meets these 172 conditions: 174 SEQUENCE { 175 OBJECT IDENTIFIER '2 5 29 30' 176 BOOLEAN TRUE 177 OCTET STRING, encapsulates { 178 SEQUENCE { 179 [0] { 180 SEQUENCE { 181 [2] 'example.com' 182 } 183 } 184 [1] { 185 SEQUENCE { 186 [7] 00 00 00 00 00 00 00 00 187 } 188 SEQUENCE { 189 [7] 190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 191 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 192 } 193 } 194 } 195 } 196 } 198 3.2.1. Presenting SCTs, Inclusion Proofs and STHs 200 Each SCT (and optional corresponding inclusion proof and STH) 201 presented by a TLS server MAY correspond to an intermediate CA 202 certificate or intermediate CA precertificate (to which the server 203 certificate chains) that meets the requirements in Section 3.2. This 204 extends section TBD of CT v2 [I-D.ietf-trans-rfc6962-bis], which 205 specifies that each SCT always corresponds to the server certificate 206 or to a precertificate that corresponds to that certificate. 208 Each SCT (and optional corresponding inclusion proof and STH) 209 included by a certification authority in a Transparency Information 210 X.509v3 extension in the "singleExtensions" of a "SingleResponse" in 211 an OCSP response MAY correspond to an intermediate CA certificate or 212 intermediate CA precertificate (to which the certificate identified 213 by the "certID" of that "SingleResponse" chains) that meets the 214 requirements in Section 3.2. This extends section TBD of CT v2 215 [I-D.ietf-trans-rfc6962-bis], which specifies that each SCT always 216 corresponds to the certificate identified by the "certID" of that 217 "SingleResponse" or to a precertificate that corresponds to that 218 certificate. 220 Each SCT (and optional corresponding inclusion proof and STH) 221 included by a certification authority in a Transparency Information 222 X.509v3 extension in a certificate MAY correspond to an intermediate 223 CA certificate or intermediate CA precertificate (to which the 224 certificate chains) that meets the requirements in Section 3.2. This 225 extends section TBD of CT v2 [I-D.ietf-trans-rfc6962-bis], which 226 specifies that each SCT always corresponds to a precertificate that 227 corresponds to that certificate. 229 TODO: Refactor this section to avoid repetition. 231 3.2.2. Matching an SCT to the Correct Certificate 233 Before considering any SCT to be invalid, a TLS client MUST attempt 234 to validate it against the server certificate and against each of the 235 zero or more suitable name-constrained intermediates in the chain. 236 These certificates may be evaluated in the order they appear in the 237 chain, or indeed, in any order. 239 TODO: Shall we specify that there MUST be no more than ONE name- 240 constrained intermediate in the chain? 242 TODO: Shall we specify that all presented SCTs MUST correspond to the 243 same (end-entity or name-constrained intermediate) certificate? 245 3.3. Redacting Labels in Precertificates 247 When creating a precertificate, the CA MAY include a 248 redactedSubjectAltName (Section 3.3.1) extension that contains, in a 249 redacted form, the same entries that will be included in the 250 certificate's subjectAltName extension. When the 251 redactedSubjectAltName extension is present in a precertificate, the 252 subjectAltName extension MUST be omitted (even though it MUST be 253 present in the corresponding certificate). 255 Wildcard "*" labels MUST NOT be redacted, but one or more non- 256 wildcard labels in each DNS-ID [RFC6125] can each be replaced with a 257 redacted label as follows: 259 REDACT(label) = prefix || BASE32(index || _label_hash) 260 _label_hash = LABELHASH(keyid_len || keyid || label_len || label) 262 "label" is the case-sensitive label to be redacted. 264 "prefix" is the "?" character (ASCII value 63). 266 "index" is the 1 byte index of a hash function in the CT hash 267 algorithm registry (section TBD of [I-D.ietf-trans-rfc6962-bis]). 268 The value 255 is reserved. 270 "keyid_len" is the 1 byte length of the "keyid". 272 "keyid" is the keyIdentifier from the Subject Key Identifier 273 extension (section 4.2.1.2 of [RFC5280]), excluding the ASN.1 OCTET 274 STRING tag and length bytes. 276 "label_len" is the 1 byte length of the "label". 278 "||" denotes concatenation. 280 "BASE32" is the Base 32 Encoding function (section 6 of [RFC4648]). 281 Pad characters MUST NOT be appended to the encoded data. 283 "LABELHASH" is the hash function identified by "index". 285 3.3.1. redactedSubjectAltName Certificate Extension 287 The redactedSubjectAltName extension is a non-critical extension (OID 288 1.3.101.77) that is identical in structure to the subjectAltName 289 extension, except that DNS-IDs MAY contain redacted labels 290 (Section 3.3). 292 When used, the redactedSubjectAltName extension MUST be present in 293 both the precertificate and the corresponding certificate. 295 This extension informs TLS clients of the DNS-ID labels that were 296 redacted and the degree of redaction, while minimizing the complexity 297 of TBSCertificate reconstruction (Section 3.3.3). Hashing the 298 redacted labels allows the legitimate domain owner to identify 299 whether or not each redacted label correlates to a label they know 300 of. 302 TODO: Consider the pros and cons of this 'un'redaction feature. If 303 the cons outweigh the pros, switch to using Andrew Ayer's alternative 304 proposal of hashing a random salt and including that salt in an 305 extension in the certificate (and not including the salt in the 306 precertificate). 308 Only DNS-ID labels can be redacted using this mechanism. However, 309 CAs can use the Section 3.2 mechanism to allow DNS domain name labels 310 in other subjectAltName entries to not appear in logs. 312 TODO: Should we support redaction of SRV-IDs and URI-IDs using this 313 mechanism? 315 3.3.2. Verifying the redactedSubjectAltName extension 317 If the redactedSubjectAltName extension is present, TLS clients MUST 318 check that the subjectAltName extension is present, that the 319 subjectAltName extension contains the same number of entries as the 320 redactedSubjectAltName extension, and that each entry in the 321 subjectAltName extension has a matching entry at the same position in 322 the redactedSubjectAltName extension. Two entries are matching if 323 either: 325 o The two entries are identical; or 327 o Both entries are DNS-IDs, have the same number of labels, and each 328 label in the subjectAltName entry has a matching label at the same 329 position in the redactedSubjectAltName entry. Two labels are 330 matching if either: 332 * The two labels are identical; or, 334 * Neither label is "*" and the label from the 335 redactedSubjectAltName entry is equal to REDACT(label from 336 subjectAltName entry) (Section 3.3). 338 If any of these checks fail, the certificate MUST NOT be considered 339 compliant. 341 3.3.3. Reconstructing the TBSCertificate 343 Section TBD of [I-D.ietf-trans-rfc6962-bis] describes how TLS clients 344 can reconstruct the TBSCertificate component of a precertificate from 345 a certificate, so that associated SCTs may be verified. 347 If the redactedSubjectAltName extension (Section 3.3.1) is present in 348 the certificate, TLS clients MUST also: 350 o Verify the redactedSubjectAltName extension against the 351 subjectAltName extension according to Section 3.3.2. 353 o Once verified, remove the subjectAltName extension from the 354 TBSCertificate. 356 4. Security Considerations 358 4.1. Avoiding Overly Redacted Domain Names 360 Redaction of domain name labels (Section 3.3) carries the same risks 361 as the use of wildcards (e.g., section 7.2 of [RFC6125]). If the 362 entirety of the domain space below the unredacted part of a domain 363 name is not registered by a single domain owner (e.g., 364 REDACT(label).com, REDACT(label).co.uk and other [Public.Suffix.List] 365 entries), then the domain name may be considered by clients to be 366 overly redacted. 368 CAs should take care to avoid overly redacting domain names in 369 precertificates. It is expected that monitors will treat 370 precertificates that contain overly redacted domain names as 371 potentially misissued. TLS clients MAY consider a certificate to be 372 non-compliant if the reconstructed TBSCertificate (Section 3.3.3) 373 contains any overly redacted domain names. 375 TODO(eranm): Describe how the CT ecosystem would be harmed if the use 376 of redaction becomes too widespread. 378 5. Privacy Considerations 380 5.1. Ensuring Effective Redaction 382 Although the mechanisms described in this document remove the need 383 for private labels to appear in CT logs, they do not guarantee that 384 this will never happen. For example, anyone who encounters a 385 certificate could choose to submit it to one or more logs, thereby 386 rendering the redaction futile. 388 Domain owners are advised to take the following steps to minimize the 389 likelihood that their private labels will become known outside their 390 closed communities: 392 o Avoid registering private labels in public DNS. 394 o Avoid using private labels that are predictable (e.g., "www", 395 labels consisting only of numerical digits, etc). If a label has 396 insufficient entropy then redaction will only provide a thin layer 397 of obfuscation, because it will be feasible to recover the label 398 via a brute-force attack. 400 o Avoid using publicly trusted certificates to secure private domain 401 space. 403 o Avoid enabling unrestricted access for DNS zone transfer (AXFR) 404 requests (see section 5 of [RFC5936]). 406 CAs are advised to carefully consider each request to redact a label 407 using the Section 3.3 mechanism. When a CA believes that redacting a 408 particular label would be futile, we advise rejecting the redaction 409 request. TLS clients may have policies that forbid redaction, so 410 label redaction should only be used when it's absolutely necessary 411 and likely to be effective. 413 6. Acknowledgements 415 The authors would like to thank Andrew Ayer and TBD for their 416 valuable contributions. 418 A big thank you to Symantec for kindly donating the OIDs from the 419 1.3.101 arc that are used in this document. 421 7. References 423 7.1. Normative References 425 [I-D.ietf-trans-rfc6962-bis] 426 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 427 Stradling, "Certificate Transparency Version 2.0", draft- 428 ietf-trans-rfc6962-bis-24 (work in progress), December 429 2016. 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, 433 DOI 10.17487/RFC2119, March 1997, 434 . 436 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 437 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 438 . 440 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 441 Housley, R., and W. Polk, "Internet X.509 Public Key 442 Infrastructure Certificate and Certificate Revocation List 443 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 444 . 446 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 447 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 448 . 450 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 451 Verification of Domain-Based Application Service Identity 452 within Internet Public Key Infrastructure Using X.509 453 (PKIX) Certificates in the Context of Transport Layer 454 Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 455 2011, . 457 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 458 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 459 . 461 7.2. Informative References 463 [EV.Certificate.Guidelines] 464 CA/Browser Forum, "Guidelines For The Issuance And 465 Management Of Extended Validation Certificates", 2007, 466 . 469 [Public.Suffix.List] 470 Mozilla Foundation, "Public Suffix List", 2016, 471 . 473 Authors' Addresses 475 Rob Stradling 476 Comodo CA, Ltd. 478 Email: rob.stradling@comodo.com 480 Eran Messeri 481 Google UK Ltd. 483 Email: eranm@google.com