Use of Name Redaction for Mass Devices
SECOM
Mitaka
Tokyo
Japan
+81 422 76 2111
tadahi-ito@secom.co.jp
SECOM
Mitaka
Tokyo
Japan
+81 422 76 2111
ro-ramiresu@secom.co.jp
Security
TRANS
Internet-Draft
This document describes mechanisms to allow CT log submitters not to submit plain certificates.
While public Certificate Transparency (CT) logs allow anyone to observe server certificates
and make confident to trust Certificate Authorities (CAs),
there are some problems scaling to mass devices.
This document describes and presents some use cases for a mechanism that retains most of the security benefits gained from using Certificate Transparency.
Many devices communicate with TLS. These devices include surveillance cameras and Network Attached Storage.
Such devices use server certificates to communicate with other devices such as smart phones.
The number of these TLS-communicating devices is expected to grow exponentially.
In contrast, efficiently searchable list of mass devices may assist attackers (typically, to construct a botnet).
In this document, I describe needs of name redaction mechanisms for those devices' certificates.
Their certificates are typically issued by an intermediate certificate authority, which is tied to the device vendor or service provider.
On the other hand, there are some organizations who issue certificates only for their own domain space (with global IP address). For that case,
CA/BForum defines "technical constraints intermediate certificate authority", and allows organizations to moderate portions of the audit process
CA/BForum BR1.5.4, according to limitation of influence in case of miss issuance.
However, Certificate Transparency v1 and
current v2 I-D.ietf-trans-rfc6962-bis26 describe protocols for publicly logging all
TLS server certificates issued by publicly trusted CAs.
CT log server also store certificates with above uses,
and can end up assisting attacker in hijacking massive numbers of devices.
In addition, it would increase burden of CT log server near future,
by exponential increase of mass devices.
I-D.draft-strad-trans-redaction-01
focused on end-entity's privacy with name redaction.
This document focuses on other aspects, such as avoiding lack of scalability, or prohibiting use on large scale Botnet.
The purpose of this document is to reinforce discussion of I-D.draft-strad-trans-redaction-01.
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.
This document relies on terminology and data structures defined in [RFC-6962-BIS-26], including STH, SCT.
The term "name redaction" refers to any kind of CT mechanism, which allow submitter not to log (possibly potion of) end-entity certificate.
The term "domain-label name redaction" refers any to kind of name redaction mechanism, which allow submitter not log domain name. Domain-label name redaction is subset of name redaction.
The term "OTA update" refers to over the air update of devices.
The term "crypt agility" refers to the ability for a protocol to easily change the cryptographic algorithms it uses over time.
The technical description of this section refers to I-D.draft-strad-trans-redaction-01.
This section briefly describes the device scalability and security for three name redaction mechanisms,
in order of increasing implementation complexity:
Using wildcard certificates is
the simplest option, but it is not suitable for use with massive numbers of devices. Devices with a common wildcard certificate would need to share a private key, which would dramatically increase risk of key leakage.
Logging a name-constrained intermediate CA certificate in place of the
end-entity certificate,
and is suitable for mass devices, as it improves the scalability of the log server. However, it requires some non-scalable operations on the part of the CA
(i.e. issuing new intermediate certificate.).
Domain-label name redaction mechanism reduces the burden put on the CA.
In addition, it allows CAs to operate mass devices more flexibly.
Furthermore, geographic information is very useful for mass device management, and service providers may want or try to use
that information with certificates.
However, this information might be useful for attacker also.
By hiding this information for attacker, this mechanism prevents large-scale physical attacks on devices.
However, this option increases the implementation complexity considerably.
When an IoT service provider uses server certificates, the service provider will choose one of following.
In this section, we describe positive and negative points for each methods
(including methods, which does not use name redaction).
Pro: Do not need any change with current mechanisms.
Con: Service providers need to construct a new trust store. As the number of IoT services increases, it will become hard to manage the trust store, both for service providers and end users. ("scalability of trust store" issue)
While private roots could be used, it could prevent interoperability, and incompatibility with modern browser software could force IoT device software to rely on custom software that likely would not receive security updates (as browser software does) leading to the same kind of problem of "frozen" legacy root stores that can't be updated that we saw during SHA-1 deprecation problems.
Since a mississued certificate for an IoT device would affect security of the Web,
Service provider would have to maintain an OTA update mechanism for IoT devices to maintain security and crypt agility.
Some of the methods below may provide incentives for service providers to use such devices.
Do not use name redaction.
Log all end-entity certificates :
Pro: Compatible with current mechanism.
Con: log server needs to deal with enormous log ("scalability of log server" issue).
IoT devices (cameras, sensors, etc.), can be proxies for DOS attacks.
Unredacted CT logs may help an DOS attacker to construct a botnet for DOS attack.
Logging Reveals Commercially Sensitive Information also.
Manufacturers using IoT certificates possibly won't want to show the number of devices
they have shipped; redaction may help keep this information private.
Competitors scanning CT logs could infer new product/service offerings prior to their public release.
Disabling CT log checking with browser policy :
Pro: Compatible with current CT Log server.
Con: Browser needs to implement mechanism, and list of intermediate CAs not to check.
Use name redaction
With wild card Certificate :
Pro : Near-compatible with current CT mechanism.
Con : Secret keys could be leaked from IoT devices.
With name-constrained intermediate CA :
Pro: Near-compatible with current log server's implementation.
Con: Browser needs to support name-constrained intermediate.
CA need to implement name-constrained intermediate.
domain-label name redaction :
If "attacker can construct *list* of devices very *efficiently*", that list can assist attacker (typically, construction of botnet).
This mechanism limits the efficiency of construction, instead of preventing the construction of a list.
TODO: describe how CA can get assurance for domain owner's control over underling domain.
It should contain some management mechanism, and need further discuss.
Portions of this text were unabashedly borrowed from I-D.draft-strad-trans-redaction-01.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
The Base16, Base32, and Base64 Data Encodings
This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]
Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
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)
Many application technologies enable secure communication between two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX) certificates in the context of Transport Layer Security (TLS). This document specifies procedures for representing and verifying the identity of application services in such interactions. [STANDARDS-TRACK]
Certificate Transparency
This document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs.Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.
Certificate Transparency Version 2.0
This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.
Certificate Transparency: Domain Label Redaction
This document defines mechanisms 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 accrued from using
Certificate Transparency.
Baseline Requirements for theIssuance and Management of Publicly-Trusted Certificates
CA/Browser Forum