Use of Name Redaction for Mass Devices
draft-ito-yet-another-name-redaction-01

Abstract

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.

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 https://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 September 3, 2018.

Copyright Notice

Copyright (c) 2018 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 (https://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.

Table of Contents

• 1. Introduction
• 2. Requirements Language
• 3. Terminology
• 4. Redacted CT submission mechanism
• 5. Concerns with each method
• 5.1. Use Private Roots (do not use name redaction nor CT)
• 5.2. Use Public Roots
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

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 [RFC6962] 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.

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 RFC 2119.

3. Terminology

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.

4. Redacted CT submission mechanism

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.

5. Concerns with each method

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).

5.1. Use Private Roots (do not use name redaction nor CT)

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.

5.2. Use Public Roots

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.

6. IANA Considerations

TBD

7. Security Considerations

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.

8. Acknowledgements

Portions of this text were unabashedly borrowed from I-D.draft-strad-trans-redaction-01.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses