Certificate Transparency: Domain Label Redaction
draft-strad-trans-redaction-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
---|---|---|---|
Authors | Rob Stradling , Eran Messeri | ||
Last updated | 2016-08-31 | ||
RFC stream | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-strad-trans-redaction-00
TRANS (Public Notary Transparency) R. Stradling Internet-Draft Comodo CA, Ltd. Intended status: Experimental E. Messeri Expires: March 4, 2017 Google UK Ltd. August 31, 2016 Certificate Transparency: Domain Label Redaction draft-strad-trans-redaction-00 Abstract We define a mechanism to allow DNS domain name labels that are considered to be private to not appear in public Certificate Transparency (CT) logs, while still retaining most of the security benefits that accrue from using Certificate Transparency mechanisms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 4, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Stradling & Messeri Expires March 4, 2017 [Page 1] Internet-Draft CT Domain Label Redaction August 2016 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3 3. Redacting Labels in Precertificates . . . . . . . . . . . . . 3 4. redactedSubjectAltName Certificate Extension . . . . . . . . 4 5. Verifying the redactedSubjectAltName extension . . . . . . . 4 6. Reconstructing the TBSCertificate . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7.1. Avoiding Overly Redacting Domain Name Labels . . . . . . 5 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 8.1. Ensuring Effective Redaction . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Some domain owners regard certain DNS domain name labels within their registered domain space as private and security sensitive. Even though these domains are often only accessible within the domain owner's private network, it's common for them to be secured using publicly trusted Transport Layer Security (TLS) server certificates. Certificate Transparency [I-D.ietf-trans-rfc6962-bis] describes a protocol for publicly logging the existence of TLS server certificates as they are issued or observed. Since each TLS server certificate lists the domain names that it is intended to secure, private domain name labels within registered domain space could end up appearing in CT logs, especially as TLS clients develop policies that mandate CT compliance. This seems like an unfortunate and potentially unnecessary privacy leak, because it's the registered domain names in each certificate that are of primary interest when using CT to look for suspect certificates. TODO: Highlight better the differences between registered domains and subdomains, referencing the relevant DNS RFCs. Section TBD of [I-D.ietf-trans-rfc6962-bis] proposes two mechanisms for dealing with this conundrum: wildcard certificates and name- constrained intermediate CAs. However, these mechanisms are insufficient to cover all use cases. TODO(eranm): Expand on when each of the other mechanisms is suitable and when this mechanism may be suitable. Stradling & Messeri Expires March 4, 2017 [Page 2] Internet-Draft CT Domain Label Redaction August 2016 We define a domain label redaction mechanism that covers all use cases, at the cost of increased implementation complexity. CAs and domain owners should note that there are privacy considerations (Section 8) and that TLS clients may apply additional requirements (relating to the use of this redaction mechanism) for a certificate to be considered compliant. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Redacting Labels in Precertificates When creating a precertificate, the CA MAY include a redactedSubjectAltName (Section 4) extension that contains, in a redacted form, the same entries that will be included in the certificate's subjectAltName extension. When the redactedSubjectAltName extension is present in a precertificate, the subjectAltName extension MUST be omitted (even though it MUST be present in the corresponding certificate). Wildcard "*" labels MUST NOT be redacted, but one or more non- wildcard labels in each DNS-ID [RFC6125] can each be replaced with a redacted label as follows: REDACT(label) = prefix || BASE32(index || _label_hash) _label_hash = LABELHASH(keyid_len || keyid || label_len || label) "label" is the case-sensitive label to be redacted. "prefix" is the "?" character (ASCII value 63). "index" is the 1 byte index of a hash function in the CT hash algorithm registry (section TBD of [I-D.ietf-trans-rfc6962-bis]). The value 255 is reserved. "keyid_len" is the 1 byte length of the "keyid". "keyid" is the keyIdentifier from the Subject Key Identifier extension (section 4.2.1.2 of [RFC5280]), excluding the ASN.1 OCTET STRING tag and length bytes. "label_len" is the 1 byte length of the "label". "||" denotes concatenation. Stradling & Messeri Expires March 4, 2017 [Page 3] Internet-Draft CT Domain Label Redaction August 2016 "BASE32" is the Base 32 Encoding function (section 6 of [RFC4648]). Pad characters MUST NOT be appended to the encoded data. "LABELHASH" is the hash function identified by "index". 4. redactedSubjectAltName Certificate Extension The redactedSubjectAltName extension is a non-critical extension (OID 1.3.101.77) that is identical in structure to the subjectAltName extension, except that DNS-IDs MAY contain redacted labels (Section 3). When used, the redactedSubjectAltName extension MUST be present in both the precertificate and the corresponding certificate. This extension informs TLS clients of the DNS-ID labels that were redacted and the degree of redaction, while minimizing the complexity of TBSCertificate reconstruction (Section 6). Hashing the redacted labels allows the legitimate domain owner to identify whether or not each redacted label correlates to a label they know of. TODO: Consider the pros and cons of this 'un'redaction feature. If the cons outweigh the pros, switch to using Andrew Ayer's alternative proposal of hashing a random salt and including that salt in an extension in the certificate (and not including the salt in the precertificate). Only DNS-ID labels can be redacted using this mechanism. However, CAs can use Name Constraints (section TBD of [I-D.ietf-trans-rfc6962-bis]) to allow DNS domain name labels in other subjectAltName entries to not appear in logs. TODO: Should we support redaction of SRV-IDs and URI-IDs using this mechanism? 5. Verifying the redactedSubjectAltName extension If the redactedSubjectAltName extension is present, TLS clients MUST check that the subjectAltName extension is present, that the subjectAltName extension contains the same number of entries as the redactedSubjectAltName extension, and that each entry in the subjectAltName extension has a matching entry at the same position in the redactedSubjectAltName extension. Two entries are matching if either: o The two entries are identical; or Stradling & Messeri Expires March 4, 2017 [Page 4] Internet-Draft CT Domain Label Redaction August 2016 o Both entries are DNS-IDs, have the same number of labels, and each label in the subjectAltName entry has a matching label at the same position in the redactedSubjectAltName entry. Two labels are matching if either: * The two labels are identical; or, * Neither label is "*" and the label from the redactedSubjectAltName entry is equal to REDACT(label from subjectAltName entry) (Section 3). If any of these checks fail, the certificate MUST NOT be considered compliant. 6. Reconstructing the TBSCertificate Section TBD of [I-D.ietf-trans-rfc6962-bis] describes how TLS clients can reconstruct the TBSCertificate component of a precertificate from a certificate, so that associated SCTs may be verified. If the redactedSubjectAltName extension (Section 4) is present in the certificate, TLS clients MUST also: o Verify the redactedSubjectAltName extension against the subjectAltName extension according to Section 5. o Once verified, remove the subjectAltName extension from the TBSCertificate. 7. Security Considerations 7.1. Avoiding Overly Redacting Domain Name Labels Redaction of domain name labels carries the same risks as the use of wildcards (e.g., section 7.2 of [RFC6125]). If the entirety of the domain space below the unredacted part of a domain name is not registered by a single domain owner (e.g., REDACT(label).com, REDACT(label).co.uk and other [Public.Suffix.List] entries), then the domain name may be considered by clients to be overly redacted. CAs should take care to avoid overly redacting domain names in precertificates. It is expected that monitors will treat precertificates that contain overly redacted domain names as potentially misissued. TLS clients MAY consider a certificate to be non-compliant if the reconstructed TBSCertificate (Section 6) contains any overly redacted domain names. Stradling & Messeri Expires March 4, 2017 [Page 5] Internet-Draft CT Domain Label Redaction August 2016 8. Privacy Considerations 8.1. Ensuring Effective Redaction Although the domain label redaction mechanism removes the need for private labels to appear in logs, it does not guarantee that this will never happen. Anyone who encounters a certificate could choose to submit it to one or more logs, thereby rendering the redaction futile. Domain owners are advised to take the following steps to minimize the likelihood that their private labels will become known outside their closed communities: o Avoid registering private labels in public DNS. o Avoid using private labels that are predictable (e.g., "www", labels consisting only of numerical digits, etc). If a label has insufficient entropy then redaction will only provide a thin layer of obfuscation, because it will be feasible to recover the label via a brute-force attack. o Avoid using publicly trusted certificates to secure private domain space. CAs are advised to carefully consider each request to redact a label. When a CA believes that redacting a particular label would be futile, we advise rejecting the redaction request. TLS clients may have policies that forbid redaction, so redaction should only be used when it's absolutely necessary and likely to be effective. 9. Acknowledgements The authors would like to thank Andrew Ayer and TBD for their valuable contributions. A big thank you to Symantec for kindly donating the OID from the 1.3.101 arc that is used in this document. 10. References 10.1. Normative References [I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency", draft-ietf-trans- rfc6962-bis-18 (work in progress), July 2016. Stradling & Messeri Expires March 4, 2017 [Page 6] Internet-Draft CT Domain Label Redaction August 2016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>. [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <http://www.rfc-editor.org/info/rfc6125>. 10.2. Informative References [Public.Suffix.List] Mozilla Foundation, "Public Suffix List", 2016, <https://publicsuffix.org>. Authors' Addresses Rob Stradling Comodo CA, Ltd. Email: rob.stradling@comodo.com Eran Messeri Google UK Ltd. Email: eranm@google.com Stradling & Messeri Expires March 4, 2017 [Page 7]