TRANS T. Ito
Internet-Draft R. Ramirez, Ed.
Intended status: Informational SECOM
Expires: September 3, 2018 March 2, 2018

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

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:

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.

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

[I-D.draft-strad-trans-redaction-01] Stradling, R. and E. Messeri, "Certificate Transparency: Domain Label Redaction", Internet-Draft draft-strad-trans-redaction-01, January 2017.
[I-D.ietf-trans-rfc6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E. and R. Stradling, "Certificate Transparency Version 2.0", Internet-Draft draft-ietf-trans-rfc6962-bis-24, December 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006.
[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.
[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.
[RFC6962] Laurie, B., Langley, A. and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013.

9.2. Informative References

[BR1.5.4] CA/Browser Forum, "Baseline Requirements for theIssuance and Management of Publicly-Trusted Certificates", 2017.

Authors' Addresses

Tadahiko Ito SECOM Mitaka, Tokyo Japan Phone: +81 422 76 2111 EMail: tadahi-ito@secom.co.jp
Robert Ramirez (editor) SECOM Mitaka, Tokyo Japan Phone: +81 422 76 2111 EMail: ro-ramiresu@secom.co.jp