Public Notary Transparency S. Kent Internet Draft BBN Technologies Intended status: Standards Track D. Mandelberg Expires: November 2016 K. Seo May 24, 2016 Certificate Transparency (CT) Requirements for Monitors and Auditors draft-kent-trans-monitor-auditor-01.txt Abstract This document establishes requirements for the Monitor and Auditor elements of the Certificate Transparency (CT) system, focusing on the Web PKI context. It defines the functions performed by these system elements. This is a companion to the CT System Architecture document (draft-kent-trans-architecture). 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 24, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Kent, et al. Expires November 24, 2016 [Page 1] Internet-Draft CT Requirements for Monitors and Auditors May 2016 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. Table of Contents 1. Introduction...................................................2 1.1. Requirements Language.....................................3 2. Monitor Requirements...........................................3 3. Auditor Requirements...........................................6 3.1. Checking MMD, STH Frequency Count and the Append-only property.......................................................7 3.2. Checking for Consistency of Log Views.....................8 4. Security Considerations........................................8 5. IANA Considerations............................................9 6. References.....................................................9 6.1. Normative References......................................9 6.2. Informative References...................................10 7. Acknowledgments...............................................10 1. Introduction Certificate Transparency (CT) is a set of mechanisms designed to deter, detect, and facilitate remediation of certificate mis- issuance. The Monitor element of CT detects mis-issuance by performing the operations described in Section 2 below, notifying the CT-aware Subjects that it serves. The Auditor element of CT detects misbehavior of logs, and notifies the Monitors that it serves, so that these Monitors can perform their functions reliably. A Monitor observes a set of logs to detect certificate mis-issuance. A Monitor notifies a Subject [CA-Subject] when a bogus (or erroneous) certificate [draft-ietf-trans-threat-analysis] has been issued on behalf of that Subject. Every CT-aware Subject is expected to either perform self-Monitoring or to arrange with a third-party Monitor to detect mis-issued certificates on behalf of the Subject. A Monitor performs its function by examining all entries from a set of logs and comparing these entries to reference data for a set of one or more Subjects. The reference data consists, at a minimum, of a list of Subject and Subject Alternative Names and the pubic key information associated with each, supplied by the Subject. If a Monitor detects a log entry for a certificate that is inconsistent Kent, et al. Expires November 24, 2016 [Page 2] Internet-Draft CT Requirements for Monitors and Auditors May 2016 with the reference data for a Subject, the Monitor notifies the Subject. A Subject may perform self-monitoring. An Auditor interacts with a log to detect misbehavior of the log. When it detects misbehavior, an Auditor notifies Monitors that have arranged for such notification. Because Browser Vendors supply log metadata in their browsers, each is expected to operate an Auditor, or to arrange to receive notifications of log misbehavior from Auditors, or both. (See [Browser-vendor] for additional details.) An Auditor detects log misbehavior by performing checks on log entries and Signed Tree Heads (STHs) [6962-bis]. One form of misbehavior (see Section 3 below) requires communication among Auditors and, perhaps, other CT system elements, and is not yet fully specified. 1.1. 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 RFC 2119 [RFC2119]. 2. Monitor Requirements As noted above, a Monitor observes a set of logs, looking for log entries of "interest". A Subject may act as a self-monitor, or may make use of the services of a third-party Monitor. In the self- monitoring context, the log entries of interest are ones that contain a Subject or Subject Alternative Name (SAN) associated with the Subject's web site(s). In the third-party Monitor context, the log entries of interest are the ones specified by its clients. Each client of a third party Monitor supplies the Monitor with a list of Subject names and SANs associated with the client's web site(s), and public key information associated with each name. Additionally, if the client intends to log name-constrained CA certificate(s) as described in Section 4.3 of [6962-bis], the client supplies the Monitor with a list of permitted dNSNames, and public key information associated with each name. The Monitor watches a set of logs looking for entries that match the client certificates of interest. A Certification Authority (CA) MAY operate a Monitor on behalf of the Subjects to which it issues certificates [CA-Subject]. In this case, the Monitor has access to the reference information needed to detect mis-issued certificates (relative to those issued by this CA). The means by which a Subject or Monitor determines which set of logs to watch is outside the scope of the CT specifications. It is Kent, et al. Expires November 24, 2016 [Page 3] Internet-Draft CT Requirements for Monitors and Auditors May 2016 anticipated that there will be a small number of logs that are widely used, and that the metadata for these logs [6962-bis] will be available from browser vendors [browser-vendor]. It is RECOMMENDED that third-party Monitors make public the set of logs that they watch, and the set of third-party Auditors they rely upon, to help clients decide which third-party Monitor(s) to use. A Monitor (self or third-party) that is observing a log periodically queries the log to determine if there is a new STH, using the get- sth interface (see Section 6.3 of [6962-bis]). When a new STH is detected, the Monitor then uses the get-entries interface to the log (see Section 6.7 of [6962-bis]) to retrieve all new log entries (relative to the previous STH acquired by the Monitor). (This command requires the Monitor to indicate the start and end entries, by index, data that is provided by get-sth.) The Monitor examines each log entry to determine if it is of interest: 1. certificates with fully-specified DNS names - If the Subject or SAN is on the list of names of interest, the Monitor checks to see if the public key in the certificate matches the public key for the specified name(s). If it does not match, then the certificate is deemed mis-issued. 2. wildcard certificate log entries - If a Monitor encounters a log entry for a name-redacted certificate (Section 4.2 in [6962-bis]), it compares the non-redacted part of the name in the log entry against the list of names of interest. If a match is found, the Monitor then compares the certificate's public key to the public key for the name. If the public key in the log entry does not match, the certificate is deemed mis-issued. 3. name-constrained CA certificates - If any of the dNSNames in the permittedSubtrees field is an ancestor of or equal to a name of interest, the Monitor checks to see if the public key in the certificate matches a public key which has been authorized for use in a name-constrained CA for the specified name(s). For any certificate deemed mis-issued, a third-party Monitor contacts the Subject and forwards the log entry, along with log metadata. (This step doesn't apply to the case of a self-monitoring Subject). The Subject contacts the CA that issued the certificate (using the Issuer name in the certificate) and requests revocation of the mis-issued certificate, to remedy the problem. The means by which a Subject determines how to contact a CA based on the issuer name is outside the scope of this specification. Kent, et al. Expires November 24, 2016 [Page 4] Internet-Draft CT Requirements for Monitors and Auditors May 2016 A Monitor MAY retain its own copies of log entries, but it is not required to do so. Local caching of log entries would be useful for a third party Monitor that acquires a new client, since the Monitor could examine the older entries for certificates that are now of interest. For a self-Monitor, maintaining a cache of old log entries may not be useful and may represent a storage burden. Note that the Monitor function, as described above, does not try to detect mis-behavior by a log. That is the responsibility of an Auditor, as described in Section 3. A system operating as a Monitor MAY incorporate some or all of the Auditor functions or it MAY make use of third-party Auditors. Because a Monitor relies on logs to behave properly in order to perform its function, every Monitor MUST acquire Auditor reports for every log that it observes. The means by which Subjects determine the set of functions provided by a third- party Monitor is not defined by this document; it may be described in a future Monitor API specification. CT does not include any mechanisms designed to detect misbehavior by a Monitor. A self-Monitor does not require such mechanisms; Subjects who elect to rely upon third-party Monitors would benefit from such mechanisms. Figure 1 illustrates the interactions between a Monitor and the other elements of the CT system. Kent, et al. Expires November 24, 2016 [Page 5] Internet-Draft CT Requirements for Monitors and Auditors May 2016 +----+ | CA |<********************* +----+ * ^ * * * v * +---------+ * | Subject |<************* * +---------+ * * ^ ^ * * * ******* * * v * * * +---------+ * * * | Browser | * * * +---------+ * * * ^ * * * * * * * v v * * +----------------+ * * | Browser Vendor |<*** * * +----------------+ * * * v v v +-----+ +---------+ | Log |<---------------------->| Monitor | +-----+ +---------+ ^ * v +---------+ | Auditor | +---------+ Legend: <---> Interface defined by CT <***> Interface out of scope for CT Figure 1 Monitor Interactions with other CT System Elements 3. Auditor Requirements Auditors perform checks intended to detect mis-behavior by logs. There are four log behavior properties that Auditors check: 1. The Maximum Merge Delay (MMD) 2. The STH Frequency Count 3. The append-only property 4. The consistency of the log view presented to all query sources Kent, et al. Expires November 24, 2016 [Page 6] Internet-Draft CT Requirements for Monitors and Auditors May 2016 The first three of these checks are easily performed using existing log interfaces and log metadata, as described below. The last check is more difficult to perform because it requires a way to share log responses among a set of CT elements, perhaps including browsers, web sites, Monitors, and Auditors, e.g., so-called gossiping [Gossip]. There is as yet no standard for gossiping and thus the last check is NOT required of Auditors at this time. +---------+ | Monitor | +---------+ ^ * v +-----+ +---------+ | Log |<--->| Auditor | +-----+ +---------+ ^ ^ # # V v +---------+ +---------+ | Browser | | Subject | +---------+ +---------+ Legend: <---> Interface defined by CT <***> Interface out of scope for CT <###> Interface proposed by [Gossip]; not yet part of CT standards Figure 2 Auditor Interactions with other CT System Elements 3.1. Checking MMD, STH Frequency Count and the Append-only property Checking that a log is behaving correctly with regard to MMD, STH Frequency Count and Append-only property MUST be performed using the algorithms described in Sections 9.3 and 9.4 of [6962-bis] (or an algorithm that yields identical results): 1. The MMD for a log is the maximum time that may elapse between the time that an SCT is issued and a log entry is created. When an Auditor executes the algorithm in Section 9.3 of [6962-bis], Step 7 enables it to detect when the MMD has been exceeded for the certificate append that triggered the new STH. The Auditor's polling period SHOULD be chosen to be small relative to the MMD in order to maximize the chance of successful detection of an MMD violation. Kent, et al. Expires November 24, 2016 [Page 7] Internet-Draft CT Requirements for Monitors and Auditors May 2016 2. To prevent the use of an STH to identify an individual log client, a log MUST NOT generate an STH more frequently than is declared in the log metadata. To verify that a log is not violating this guarantee, when an Auditor executes the algorithm in Section 9.3 of [6962-bis], Step 5 enables it to determine how long it has been since the STH changed and to detect if this period is shorter than the minimum required. The Auditor's polling period SHOULD be chosen to be more frequent than the minimum frequency in order to maximize the chance of successful detection of too frequent generation of STHs. 3. In order to verify the append-only property, an Auditor executes the algorithm as described in Section 9.4.2 of [6962- bis]. 3.2. Checking for Consistency of Log Views In order for an Auditor to verify that a log provides a consistent view to all query sources, the Auditor needs to see the results of queries to the log from a broad range of requesters. In principle this could be accomplished using a gossip protocol that has the following constraints: 1. TLS clients are not expected to interact directly with a Log for performance and privacy reasons (see [Browser-vendor]). 2. TLS clients generally do not communicate directly with one another (with a few exceptions). As such, a gossip protocol would be easier to deploy if it does not rely on direct communication among TLS clients. 3. If TLS clients have to acquire and distribute CT information about the web sites they visit, this should not overburden the browsers, Subject web sites, or Logs. 4. Security Considerations CT is a system created to improve security for X.509 public key certificates, especially in the Web PKI context. An attack analysis [draft-ietf-trans-threat-analysis] examines the types of attacks that can be mounted against CT, to effect mis-issuance, and how CT addresses (or fails to address) each type of attack. That analysis is based on the architecture described in this and other documents, and thus readers of this document are referred to that one for a thorough discussion of the security aspects of CT. Briefly, CT logs represent a viable means of deterring semantic mis-issuance of certificates. Monitors are an effective way to detect semantic mis- issuance of logged certificates. The CT architecture enables Kent, et al. Expires November 24, 2016 [Page 8] Internet-Draft CT Requirements for Monitors and Auditors May 2016 certificate Subjects to request revocation of mis-issued certificates, thus remedying such mis-issuance. Residual vulnerabilities exist with regard to some forms of Log, Auditor and Monitor misbehavior, because the architecture does not include normative means of detecting such behavior. For example: 1. The CT architecture does not incorporate a means to detect misbehavior by a third-party Monitor. This is a residual vulnerability for Subjects. A Subject may mitigate this vulnerability by performing self-monitoring or by becoming a client of more than one third-party Monitor. 2. An Auditor can fail to report misbehavior by a log when such misbehavior occurs. To detect this, a Monitor can make use of multiple Auditors, or can perform Audit functions on its own behalf. 3. Until a mechanism is standardized to detect logs that provide split views to different log clients, this form of log misbehavior may go undetected for an extended period. The current design does not ensure the ability of Monitors to detect syntactic mis-issuance of certificates. This is because provisions for asserting the type of certificate being issued, for inclusion in an SCT, have not been standardized. 5. IANA Considerations 6. References 6.1. Normative References [Merkle] Merkle, R. C. (1988). "A Digital Signature Based on a Conventional Encryption Function." Advances in Cryptology - CRYPTO '87. Lecture Notes in Computer Science 293. p. 369 [6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. Stradling, "Certificate Transparency," draft-ietf-trans- rfc6962-bis-11 (work in progress), November 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. Kent, et al. Expires November 24, 2016 [Page 9] Internet-Draft CT Requirements for Monitors and Auditors May 2016 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011. [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, June 2013. [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension," RFC 6961, June 2013. 6.2. Informative References [draft-ietf-trans-threat-analysis] Kent, S., "Attack Model and Threat for Certificate Transparency," draft-ietf-trans- threat-analysis-03 (work in progress), October 2015. [Gossip] Nordberg, L., Gillmor, D., and Ritter, T., "Gossiping in CT," draft-ietf-trans-gossip-01 (work in progress), October 2015. [Browser-vendor] Mandelberg, D. and S. Kent, "Certificate Transparency (CT) Browser Requirements," draft-dseomn- trans-browsers-00 (work in progress), November 2015. [CA-Subject] TBD 7. Acknowledgments Kent, et al. Expires November 24, 2016 [Page 10] Internet-Draft CT Requirements for Monitors and Auditors May 2016 Authors' Addresses Stephen Kent BBN Technologies 10 Moulton St. Cambridge, MA 02138 US Email: kent@bbn.com David Mandelberg Email: david@mandelberg.org Karen Seo Email: kseo@alum.mit.edu Kent, et al. Expires November 24, 2016 [Page 11]